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SYSTEM TME 1 HOD ATOTAK TICLE OF MANUFACTURE FOR " 
INITIATION OF BIDDING IN A VIRTUAL TRADE FINANCIAL 

ENVIRONMENT 

FIELD OF THE INVENTION 

The present invention relates to networked interfaces and more particularly to 
conducting trade finance business operations such as initiating bidding in a network- 
based environment. 

BACKGROUND OF THE INVENTION 

In international sales of goods, the buyer and seller may not know each other, or may 
not be familiar with the other's legal system. Thus, one of the major difficulties in 
international trade is to assure payment, particularly when the buyer or the seller is a 
small or medium sized business which expects difficulties in obtaining payment 
should a problem arise. Conventionally, a letter of credit is used in international 
trade to shift transaction risks to parties better able to manage these risks, 
specifically, to shift payment risks from unknown entities, such as a distant buyer, to 
known entities, such as a local bank. 

A letter of credit (L/C) is usually an irrevocable undertaking by a bank to pay the 
beneficiary of the letter, for example, a seller of goods, specified sums of money 
when certain conditions are fulfilled, to be charged to the account of the person, for 
example, the buyer of the goods, who causes the bank to issue the letter of credit. 

Generally, after a buyer and seller have made an agreement for the sale of goods, the 
buyer instructs its bank to open an L/C in favor of the seller. The buyer's bank 
advises the seller's bank that an L/C has been opened in favor of the seller, and the 
seller's bank accepts the buyer's bank's guarantee to pay. The seller's bank advises 



the seller that an L/C has been opened in its favor, and the conditions which must be 
fulfilled for payment to occur. Usually, the sellers bank makes an irrevocable 
promise to pay the seller upon presentation of appropriate documents. The L/C 
document is considered an asset of the seller, and can be sold or assigned by the 
seller. 

Documentation which the seller usually must present to obtain payment includes a 
bill of lading from its shipper, an invoice identifying the purchase, an appropriate 
insurance certificate, a certificate of inspection from an inspection firm confirming 
that the required goods are being shipped, export licenses and/or health inspection 
certificates, and certificates of origin used by customs personnel. After the correct 
documents are presented, the sellers bank pays the seller, then collects payment 
from the buyer's bank and delivers the presented documents to the buyer's bank. In 
turn, the buyer's bank obtains payment from the buyer. 

Meanwhile, the shipper, via a carrier, transports the goods to the buyer's location. 
The carrier requires presentation of the bill of lading, which was delivered to the 
seller, before transferring possession of the goods to the buyer. 

The buyer obtains the bill of lading from its bank after payment, and then the buyer 
and its broker arrange for presentation of the bill of lading to the carrier and delivery 
of the goods to the buyer's location. Often, the carrier delivers the goods to the 
buyer's broker at the customs entry point of the buyer's country. 

During an international trade using a conventional letter of credit, the buyer and 
seller are assumed to be located in countries B and S, respectively. The issuing bank 
is a bank in country B which has agreed with the buyer to issue a letter of credit in 
favor of the seller. The paying bank is a bank in country S known to the seller which 
has guaranteed the letter of credit to the seller. The intermediary bank, which may be 
in country B, country S or a third country, is a bank trusted by both the issuing bank 
and the paying bank. 
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To begin, the buyer issues a purchase order based on an agreement previously 
concluded between the buyer and the seller. Then, the buyer approaches its chosen 
issuing bank and instructs the issuing bank to open a letter of credit in favor of the 
seller confirmed on its chosen paying bank. The letter of credit may be confirmed, 
unconfirmed or standby. In a standby letter of credit, if the transaction proceeds 
properly, the standby L/C expires, but if the transaction does not proceed properly, 
the damaged party draws on the standby L/C. 

The issuing bank is assumed in this example to have no direct relationship with the 
paying bank, so the issuing bank approaches an intermediary bank which accepts the 
guarantee to pay of the issuing bank. The intermediary bank then approaches the 
paying bank, which accepts the guarantee to pay of the intermediary bank. 

The paying bank then advises the seller that an L/C has been opened in its favor and 
that upon presentation of appropriate confirming documentation, including the Bill 
of Lading from a Shipper, the paying bank will pay the seller. In this scenario, that 
is, assuming a confirmed L/C, the paying bank must pay without recourse upon 
presentation of appropriate documentation. In other cases, the paying bank has 
recourse, that is, the paying bank passes the documentation to the issuing bank and 
obtains payment therefrom before paying the seller. 

The seller finishes producing the goods and arranges for shipment with a shipper. 
Goods are passed to the shipper. The shipper transports the goods to a port of entry 
in the buyer's country. 

Upon receipt of goods, the shipper provides the seller with a bill of lading. The seller 
presents the bill of lading and other confirming documentation to its paying bank in 
order to collect against the L/C. After verifying that the documentation is in order, 
the paying bank pays the seller. 

The paying bank presents the documentation and its proof of payment to the 
intermediary bank, which pays the paying bank. The intermediary bank in turn 



presents the documentation and its proof of payment to the issuing bank, which pays 
the intermediary bank. The issuing bank then obtains payment from the buyer and 
gives the buyer the confirming documentation including the bill of lading. 

The buyer gives its agent, such as a broker, the bill of lading and other necessary 
documentation. The buyer's agent obtains the goods from the shipper, clears the 
goods through customs in country B and arranges for delivery of the goods to the 
buyer. The international trade is now completed. 

An L/C shields the seller from the risk of non-payment by the buyer and reduces the 
risk to the buyer that the buyer will pay for goods not received. With the L/C, the 
risk of non-payment is assumed substantially by the buyer's bank, which is assumed 
to be able to evaluate the risk of non-payment by the buyer. The seller's bank 
assumes the risk of non-payment by the buyer's bank, which the seller's bank is 
assumed to be able to evaluate. The banks require fees to compensate them for their 
risks and the expenses they incur in connection with the L/C. Typically the buyer's 
bank also requires that the buyer pledge collateral such as cash or marketable 
securities against the L/C or otherwise reduces its exposure in the event of non- 
payment by the buyer. These bank fees and requirements are a burden on trade, 
particularly on the buyer. Also, the delay involved in establishing an L/C for each 
transaction is a burden on trade. 

Problems multiply because the L/C mechanism separates the transaction into 
substantially independent contracts, namely, the contract for the sale of goods from 
buyer to seller, the bill of lading, and the letter of credit. 

One fertile source of difficulties for the seller is that its bank usually requires that all 
the documents called for in the L/C exactly correspond with the terms of the L/C, 
and withholds payment to the seller even due to typographical errors and minor 
misspellings. This has caused an enormous amount of frustration to sellers seeking 
payment. 



Another problem is that the L/C holder can obtain payment with the correct 
documents, even if shipment has not actually occurred. 

Yet another problem is that the L/C document itself has value, so there are expenses 
5 associated with its custody and in assuring that it is genuine. 

A bank incurs roughly the same expenses in connection with an L/C, independent of 
the value of the goods to which the L/C pertains. The bank's fee is sometimes 
expressed as a percentage of the amount of the L/C, such as 1%. Assuming, for 

10 example, that the bank's expenses are $10,000, it will be appreciated that the bank is 
reluctant to open an L/C for transactions involving less than $ 1 ,000,000 of goods, as 
this business is not profitable for the bank. Thus, it is difficult for parties wishing to 
participate in international trade to use the L/C mechanism when the value of the 
goods involved in a transaction is small enough that the expense of an L/C becomes 

1 5 significant. 



SUMMARY OF THE INVENTION 

A system, method and article of manufacture are provided for initiating bidding in a 
virtual trade financial environment. First, a form is submitted to a plurality of buyers 
5 providing details on products or services available from a plurality of sellers. This is 
to prompt the submission of bids on the products or services. The bids are then 
received from the buyers utilizing a network. Thereafter, the bids are categorized 
based on a predetermined criteria. The categorized bids are subsequently sent to the 
sellers utilizing the network. Offers are then received from the sellers in response to 
10 the bids utilizing the network. The offers are displayed to the buyers for closing 
transactions between the buyers and the sellers. 

In one embodiment of the present invention, an identity of the buyers is 
authenticated prior to submitting the form thereto. The identity is authenticated by 
1 5 requiring the submission of an identifier and a password. As an option, the step of 
categorizing the bids may include ranking or segmenting the bids. 

In another embodiment of the present invention, the criteria may include a 
geography and/or product category. Further, the bids and offers may be displayed on 
20 a site on the network. 
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BRIEF DESCRIPTION OF THE DRAWINGS 

The invention will be better understood when consideration is given to the following 
detailed description thereof. Such description makes reference to the annexed 
drawings wherein: 

Figure 1 is a general depiction of a VTrade environment based on Internet 
utilization; 

Figure 2 is a diagram of the trade platform over which buyer and seller processes 
take place in real time; 

Figure 3 illustrates several eCommerce capabilities of the VTrade system, including 
elnformation Convergence, eProcurement, eBilling and elnvoicing, and 
eAuctioning; 

Figure 4 is a schematic diagram of a hardware implementation of one embodiment 
of the present invention; 

Figure 5 illustrates a process for affording a virtual trade financial framework; 

Figure 6 illustrates a variation of the process of Figure 5; 

Figure 7 illustrates operation of a virtual trade financial framework; 

Figure 8 depicts optional enhancements that may be offered and performed during 
operation of the virtual trade financial framework of Figure 7; 

Figure 9 illustrates several areas which VTrade will fulfill in the eCommerce value 
chain; 
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Figure 10 depicts a process flow of the VTrade framework; 

Figure 11 illustrates a process for application of a line of credit and access to the 
VTrade system for a buyer; 

Figure 12 illustrates a process for application for access to the VTrade system by a 
seller/merchant; 

Figure 13 is a flowchart of a process for initiating bidding in a virtual trade financial 
environment; 

Figure 14 expands on the bidding process of the VTrade system discusses above 
with reference to Figure 13; 

Figure 15 is a flowchart illustrating a process for initiating a transaction in a virtual 
trade financial framework; 

Figure 16 is a flow diagram which expands on the process of Figure 15; 

Figure 17 is a flow diagram for initiation of a transaction between a buyer and seller 
using combined purchase order proforma invoice submission; 

Figure 18 illustrates a process for a payment transaction during a trade; 

25 Figure 19 illustrates a payment process when there is no disagreement on the terms 
of the documents; 

Figure 20 depicts a payment process when there is a disagreement on the terms of 
the documents; 
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igure 21 depicts a process for account settlement and/or financing for a buyer 
(importer) in the VTrade system; 

Figure 22 illustrates a payment process when a direct transfer of funds is available; 

5 

Figure 23 is a flowchart illustrating a process for completing a purchase 
order/invoice; 

Figures 24A and 24B illustrate a Purchase Order Performa Invoice (POPI); 

£3. 

10 ' ' 

^ Figure 25 depicts a combined Purchase Order Performa Invoice; 

□ Figure 26 is a flowchart depicting a process for creating a finalized document 

j| ; relating to a transaction; 

M 15 Figure 27 illustrates the Main Menu Page of an electronic document checklist which 
r ij; may be used during the process of Figure 26; Figure 28 is a flowchart illustrating a 

1 if process for creating a financial transaction-related document; 

Figure 29 illustrates a Document Page of an electronic document creator; 

20 

Figure 30 depicts an electronic Documents Checklist; 

Figure 31 illustrates a VTrade compliance engine; 

25 Figure 32 illustrates a first option of documentary compliance in a VTrade system; 

Figure 33 illustrates a second option of documentary compliance in which the Bank 
checks physical documents while VTrade checks electronic documents; 
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Figure 34 illustrates a third option of documentary compliance in which the buyer 
checks physical documents while VTrade checks electronic documents; Figure 35 
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illustrates a general architecture of the VTrade system, including a buyer station, a 
seller station, a processing hub, and a credit provider system; 

Figure 36 illustrates an exemplary technical framework for a VTrade system; 

5 

Figure 37 illustrates several potential security threats, including viruses, and internal 
attacks; 

Figure 38 illustrates security features which may be used with the technical 
framework of the VTrade system; 

Figure 39 illustrates several security principles and the services which provide them; 

Figure 40 illustrates an embodiment of the present invention in which VTrade 
operates under applicable Visa Card and international commerce rules, with an 
avenue for dispute resolution via the ICC international court for arbitration; 

Figure 41 illustrates a legal framework when the rules are set by the VTrade 
Enterprise; 

Figure 42 depicts the legal responsibilities of VTrade and the Bank; 

Figure 43 illustrates the legal responsibilities of the buyer and seller; 

25 Figure 44 shows a process for credit application and access; 

Figure 45 shows the continuation of the process for credit application and access of 
Figure 44; 
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Figure 46 depicts a process for initiation of bidding; 



Figure 47 illustrates a process for submission of a VTrade POPI; 

Figure 48 illustrates a continuation of the process for submission of a VTrade POPI 
of Figure 47; 

Figure 49 depicts a process for negotiation and finalization of the POPI; 

Figure 50 illustrates a process for facilitation of document checking during payment; 

Figure 51 illustrates continuation of the process for facilitation of document 
checking during payment; 

Figure 52 illustrates a process for account billing and VTrade account management; 

Figure 53 depicts three basic forms that eMarketplaces can take to serve different 
market functions; 

Figure 54 illustrates how the three marketplaces of Figure 53 may be brought 
together to create an eMarketplace; 

Figure 55 depicts a technical infrastructure of an eMarket; 

Figure 56 is a table setting forth descriptions of elements of the infrastructure 
including software/solutions, IT, fulfillment, and financial services/risk 
management; 

Figure 57 is a table setting forth a process to create solutions to specific needs during 
a buy and sell process; 

Figure 58 illustrates another embodiment of the process for creating solutions to 
specific needs during a buy and sell process; 
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Figure 59 illustrates an embodiment of the present invention provides that offers an 
integrated package of eEnabled financial services products in one or more of the five 
categories; 

Figure 60 illustrates a TradeDirect system in accordance with one embodiment of 
the present invention; 

Figure 61 illustrates how TradeDirect may connect to outside firms to provide a 
wide breadth of services; 

Figure 62 depicts products/services that may be offered by one embodiment of the 
present invention; 

Figure 63 illustrates a process for affording credit rating and reporting utilizing a 
network; 

Figure 64 is a flowchart of a process for approving a line of credit of a buyer 
utilizing a network; 

Figure 65 is a flowchart illustrating a process for affording a settlement function 
utilizing a network; 

Figure 66 is a flowchart that illustrates a process for affording information services 
while facilitating a transaction between a buyer and a seller utilizing a network; 

Figure 67 is a flowchart depicting a process for contracting and fulfilling a business 
to business trade utilizing a network according to one embodiment of the present 
invention; 

Figure 68 illustrates a process for allowing buyers and sellers to gather information 
about each other; 
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Figure 69 is a flowchart that depicts a process for a credit application process; 

Figure 70 illustrates a process for screening a buyer before credit is given to the 
5 buyer by a credit provider; 

Figure 71 depicts a process for allowing a company to guard against risk before 
entering into a trade by allowing purchase of a risk management product; 

Figure 72 is a flowchart illustrates a process for initiation of an agreement utilizing a 
network; 

Figure 73 illustrates a process for initiating a transaction which includes an 
ePayment; 

Figure 74 illustrates a process for order fulfillment utilizing a network; 

Figure 75 illustrates a process for a transaction in which a buyer sends an ePayment; 

20 Figure 76 is a flowchart of a process for performing a direct fund transfer utilizing a 
network; 

Figure 77 illustrates a process for open accounts information in accordance with an 
embodiment of the present invention; 

25 

Figure 78 is a flowchart illustrating a process for account settlement utilizing a 
network; 

Figure 79 illustrates a process for financing or settling an account according to one 
30 embodiment of the present invention; 
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Figure 80 illustrates a process for procuring information during the course of a 
transaction in accordance with an embodiment of the present invention; 

Figure 81 is an illustration of the Integrated Development Environment Architecture 
5 (IDEA); 

Figure 82 is an illustration showing a Development Organization Framework in 
accordance with one embodiment of the present invention; 

10 Figure 83 is an illustration showing a security organization functional according to 
one embodiment of the present invention; 

Figure 84 is an illustration showing the responsibilities of an Environmental 
Management Team; 

15 

Figure 85 is an illustration showing the responsibilities of an Application Team 
structure; 

Figure 86 is an illustration showing a model migration plan in accordance with one 
20 embodiment of the present invention; 

Figure 87 is an illustration showing a single release capability development pipeline 
in accordance with one embodiment of the present invention; 

25 Figure 88 is an illustration showing a multiple release capability development 
pipeline in accordance with one embodiment of the present invention; 



Figure 89 is an illustration showing a multiple release capability development 
pipeline with code base synchronization among three pipelines; 
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Figure 90 is an illustration showing a Development Tools Framework in accordance 
with one embodiment of the present invention; 

Figure 91 is an illustration showing information captured in the Repository and 
reused; 

Figure 92 is an illustration showing the Repository's central role in the development 
environment; 

Figure 93 is an illustration showing an Operational Architecture Framework in 
accordance with one embodiment of the present invention; 

Figure 94 illustrates an eCommerce Application Framework in a Development 
Architecture Framework; 

Figure 95 illustrates the relationship between the eCommerce Application 
Framework, possible eCommerce Selling Models, enabling technology, and 
enabling eCommerce Software Packages; 

Figure 96 depicts the Relationship Management section of the eCommerce 
Application Framework in accordance with one embodiment of the present 
invention; 

Figure 97 illustrates a conceptual personalization architecture for implementing the 
Relationship Management section of the eCommerce Application Framework; 

Figure 98 illustrates a simple personalization process; 

Figure 99 is a graphical depiction of extents of personalization; 
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Figure 100 illustrates a content catalog that can be used to manage an enterprise's 
content; 

Figure 101 illustrates an exemplary template with three Dynamic Content Areas 
5 (DCAs) embedded within the template in accordance with a method of associating a 
rule and content to an interaction; 

Figure 102 depicts a ShARE (Selection, Acquisition, Retention, and Extension) 
customer relationship model which addresses the changes in a shift to interactive 
10 marketing; 

Figure 103 illustrates a flowchart for a method for administrating an e-Commerce 
system on a network in accordance with an embodiment of the present invention; 

15 Figure 104 illustrates components of the maintenance and administration portion of 
the of the eCommerce Application Framework in accordance with one embodiment 
of the present invention; 

Figure 105 illustrates the Order Processing portion of the eCommerce Application 
20 Framework of the present invention; 

Figure 106 illustrates a flowchart for a method for completing a transaction over a 
network in accordance with an embodiment of the present invention; 



25 Figure 107 depicts an example flow of business capabilities needed for complete 
order processing on an eCommerce implementation; 

Figure 108 illustrates a flowchart for a method for electronically serving a customer 
over a network in accordance with an embodiment of the present invention; 
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Figure 109 illustrates key customer services of the Customer Services portion of the 
eCommerce Application Framework; 

Figure 110 illustrates the Security component of the eCommerce Application 
5 Framework in accordance with one embodiment of the present invention; and 

Figure 111 illustrates a flowchart for a method for ensuring security of an e- 
Commerce system on a network in accordance with an embodiment of the present 
invention. 
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DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 

Virtual Trading (VTrade) is a "method" of conducting the trade finance business 
that achieves the same results as traditional trade finance through a new value 
proposition and a rethought process. In the VTrade operating model, physical 
documents are reduced. The number of parties involved are kept to the minimal. 
Three key components of VTrade model are: - VTrade Enterprise, Payment Network 
and a Bank. It should be noted that though "Bank" is used throughout this 
document, it is intended that the term include any type of credit provider. 

VTrade Enterprise provides a one-stop trade financelservice via the Internet. It is a 
highly efficient process excellence factory with full automation in handling credit 
application, payment, trade document submission and other critical processes. The 
Bank extends trade credit to the buyers and provides funding for the trade 
transaction. 

The following are some of the features and benefits provided by the VTrade system. 

• Standardisation facilitation of integration of trading partners' business 
processes and systems 

• Business Process Integration integration of the eCommerce process 
with the back-office systems of the trading partners and users 

• Electronic medium infrastructure carrying digital information from one 
entity to the other 



• Security combination of technologies in order to create a secure and 
trusted environment 
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Trust trusted third-parties provide various elements of trust such as 
Registration and Certification Authority 

Regulation and Legal Framework appropriate norms and regulations to 
create a suitable and stable frame of reference is required to stimulate 
electronic transactions 

Navigation services that help users to be informed and guided towards the 
various services and trade partnersCommunities users interacting with 
one another will quickly transform their relationship to become a 
community, as buyers and sellers find themselves sharing common needs 
and/or business processes 

Inexpensive Unlike other financial EDI business model, cost justification 
will not be an issue for VTrade with the roll-out of an inexpensive web-based 
application 

Unique Payment Rules Introduces a unique hybrid of e-Commerce and 
Visa Card payment rules for quicker dispute resolution for the international 
trading communityTrade Facilitation Unleashes the power of trade 
facilitation to ensure that majority of trade transactions are settled using the 
electronic trade facilitation engine 

Seamless Payment Introduces a seamless e-Payment capability 
throughout the trade finance value chain 

International Trading Unlike other offerings, VTrade does not focus only 
on local or regional trade, but also on international trading, with a range of 
supporting facilitation services which will help Visa Members to develop a 
range of additional revenue sources from repeat business 
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• Innovative Product Offerings Focuses on core Trade Finance 
business supported by other innovative product offerings developed 
exclusively for Visa Members. VTrade has treasury and cash management 
product capability built-inStrategic Partnership Improve business 
5 connectivity of companies through vast global network, riding on the reliable 

network of Visa and international banks 
VTrade deals in the underlying goods that are financed while traditional Trade 
Finance deals with the documents associated with the goods which are financed. 
VTrade eliminates documents usually associated with international trade. It 
10 supports international trade in a similar fashion to the way credit card supports retail 
commercial transactions. VTrade is to international trade finance transactions as 
what ATMs are to the retail banking transactions. VTrade allows "Trade Finance" 
transactions to be carried out at substantially lower cost than traditional Trade 
Finance transactions 
15 VTrade removes the inefficiencies in traditional Trade Finance business by 

eliminating the handling of documents which acted as surrogate to the actual goods 
traded. In traditional Trade Finance, documents were used as surrogate to facilitate 
the proximity of payment of a trade transaction to the event of taking delivery of 
goods. In VTrade, the process of processing the documents which are required 
20 under traditional Trade Finance is eliminated. Hence, VTrade is able to deliver the 
same results as traditional Trade Finance at a much lower cost. 
The following table contrasts traditional trade finance and the VTrade environment. 



Table 1 

Trade Finance (Letters of Credit) Heavily centered around documentary 

checking by multiple banks which 
Buyer and seller trade settlement slows down payment turnaround. 80% 

through multiple intermediating 35 of trade documents are 'discrepant" 

30 banks and average order to payment is 

around 9 months 



Processes are cumbersome because 
letters of credit are more sophisticated 

More expensive due to more parties 
involved (more than 2 banks) and 
cumbersome processes 

Payment is through SWIFT and other 
more expensive payment network 
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VTrade 

Buyer and seller trade settlement 
through buyer's bank only 

15 

Document checking performed by 
buyer, payment will be faster using 
VTrade Rules. Discrepancies will be 
20 greatly reduced with trade facilitation 
methods like electronic POPI and 
Document Checklist 



Process more streamlined because 
25 POPI terms are simpler 

Cheaper because of disintermediation 
and streamlined processes 



30 

Payment through Visanet, which is 
cheaper 



Some of the benefits that the VTrade system offers an exporter include: 

• -Costs less than the traditional bank letter of credit product. Traditional 
banks LC cost the exporter from 25-50 basis points of the LC amount. 
VTrade eliminates amendment fees, discrepancy fees, SWIFT fees and Telex 
fees 
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• •Reduces internal costs through a decrease in the use of paper, mail, and 
messenger / courier expenses. VTrade simply eliminates paper thereby 
streamlining the flow of the trade process 

• •Increases cash flow through faster payments. VTrade is integrated with 
banks to guarantee payments are transferred exactly according to the 
buyer/seller contract. 

• •Provides the potential to obtain better foreign exchange rates 

• 'Assures greater accuracy, efficiency and information flows. VTrade 
connects all parties to a transaction thereby facilitating communication and 
information sharing. 

• -Increase sales potential through more competitive product pricing 

• -Permits direct control over trade process without an intermediary. VTrade 
allows the importer and the exporter to set the terms of their contract and 
control their own transaction 

• VTrade allows the importer and the exporter to set the terms of their contract 
and control their own transaction. 

Some of the benefits that the VTrade system offers an importer include: 

• -Costs less than the traditional bank letter of credit product. Traditional bank 
LC cost 25-50 basis points of the LC amount 

• -Reduces internal costs through a decrease in the use of paper, mail, and 
messenger / courier expenses. VTrade simply eliminates paper thereby 
streamlining the flow of the trade process. 

• -Decreases turn-around-time (order-shipment-delivery) 
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• •VTrade connects all parties to a transaction thereby facilitating 
communication and information sharing. 

• •Provides the potential to negotiate lower cost of goods from the exporter, 
since payment risks are eliminated. 

• -Permits direct control over the trade process without an intermediary. 
VTrade allows the importer and the exporter to set the terms of their contract 
and control their own transaction. 

Figure 1 is a general depiction of a VTrade environment 100 based on Internet 102 
utilization. A hub 104 controls and/or monitors operations and transactions in the 
environment, and particularly across the trade platform 106 between buyers 108 and 
sellers 110. Also included is a payment network 112. 

Figure 2 is a diagram of the trade platform 106 over which buyer and seller 
processes take place in real time. In the VTrade enterprise 200, supply 202 is 
integrated with demand 204 to facilitate interaction and transaction between the 
buyer 1 08 and seller 110. 

Figure 3 illustrates several eCommerce capabilities of the VTrade system, including 
elnformation Convergence 300, eProcurement 302, eBilling and elnvoicing 304; and 
eAuctioning 306. 

The general steps to set up the VTrade system are as follows: 

1 . Buyer registers and subscribes to VTrade 

2. Credit Provider will assess the credit worthiness of the buyer and grant the 
appropriate trade finance credit line to the buyer 

3. Buyer will receive the necessary security access to transact in VTrade 

4. Register the buyer's suppliers with VTrade 

5. Sellers will receive the necessary security access to transact in VTrade 

The general steps of a transaction in the VTrade system are: 
1. Buyer and Seller negotiate terms 
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2. Buyer submit purchase order with the delivery, payment and other trade terms as 
agreed with the seller 

3. Transaction routed to credit provider for credit approval if approval is required 

4. Confirmation sent to Seller 

5. Goods Shipped to Buyer 

6. Buyer accepts goods. Payment released to Seller according to payment terms and 
debt is owed to the credit provider where credit is involved 

Table 2 illustrates the general roles of the parties in the VTrade system. 



Table 2 
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Party 


Roles 


Credit Provider 


• Market KTrade to organisation which large 
importers 

• Provide credit financing 

• Guarantee importer's credit worthiness 

• Syndicate credit requirements 

• Negotiate exporters' receivables 

• Provide FX services 

• Syndicate PTrade to insurance and shipping 
companies 

• Syndicate KTrade to other banks 


VTrade Enterprise 


• Establish the JTrade Processing HUB and 
business capability 

• Provide a secured environment for 
transacting 

• V^FUCIalC U1C r llaUC i IvJl^Coo-LLlg OVJD 

• Develop the necessary infrastructure to 
supportthe PTrade Processing 

• Market solution to Credit Provider 

• Assist Credit Provider in the marketing 
process to importer, exporter, insurance 
companies, shipping companies and etc 

• . Provide Support parties in PTrade 


Importer 


• Subcribe to FTrade and transact all 
intermediated trade transaction through 
KTrade 


Exporter 


• Subcribe to KTrade and transact all 
intermediated trade transaction through 
VTrade 



A preferred embodiment of a system in accordance with the present invention is 
preferably practiced in the context of a personal computer such as an IBM 
compatible personal computer, Apple Macintosh computer or UNIX based 
5 workstation. A representative hardware environment is depicted in Figure 4, which 
illustrates a typical hardware configuration of a workstation in accordance with a 
preferred embodiment having a central processing unit 410, such as a 
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microprocessor, and a number of other units interconnected via a system bus 412. 
The workstation shown in Figure 4 includes a Random Access Memory (RAM) 414, 
Read Only Memory (ROM) 416, an I/O adapter 418 for connecting peripheral 
devices such as disk storage units 420 to the bus 412, a user interface adapter 142 for 

5 connecting a keyboard 424, a mouse 426, a speaker 428, a microphone 422, and/or 
other user interface devices such as a touch screen (not shown) to the bus 412, 
communication adapter 424 for connecting the workstation to a communication 
network (e.g., a data processing network) and a display adapter 426 for connecting 
the bus 412 to a display device 428. The workstation typically has resident thereon 

10 an operating system such as the Microsoft Windows NT or Windows/95 Operating 
System (OS), the IBM OS/2 operating system, the MAC OS, or UNIX operating 
system. Those skilled in the art will appreciate that the present invention may also 
be implemented on platforms and operating systems other than those mentioned. 

15 A preferred embodiment is written using JAVA, C, and the C++ language and 

utilizes object oriented programming methodology. Object oriented programming 
(OOP) has become increasingly used to develop complex applications. As OOP 
moves toward the mainstream of software design and development, various software 
solutions require adaptation to make use of the benefits of OOP. A need exists for 

20 these principles of OOP to be applied to a messaging interface of an electronic 
messaging system such that a set of OOP classes and objects for the messaging 
interface can be provided. 

OOP is a process of developing computer software using objects, including the steps 
25 of analyzing the problem, designing the system, and constructing the program. An 
object is a software package that contains both data and a collection of related 
structures and procedures. Since it contains both data and a collection of structures 
and procedures, it can be visualized as a self-sufficient component that does not 
require other additional structures, procedures or data to perform its specific task. 
30 OOP, therefore, views a computer program as a collection of largely autonomous 
components, called objects, each of which is responsible for a specific task. This 
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concept of packaging data, structures, and procedures together in one component or 
module is called encapsulation. 

In general, OOP components are reusable software modules which present an 
5 interface that conforms to an object model and which are accessed at run-time 

through a component integration architecture. A component integration architecture 
is a set of architecture mechanisms which allow software modules in different 
process spaces to utilize each others capabilities or functions. This is generally done 
by assuming a common component object model on which to build the architecture. 
10 It is worthwhile to differentiate between an object and a class of objects at this point. 
An object is a single instance of the class of objects, which is often just called a 
class. A class of objects can be viewed as a blueprint, from which many objects can 
be formed. 

15 OOP allows the programmer to create an object that is a part of another object. For 
example, the object representing a piston engine is said to have a composition- 
relationship- with the object representing a piston. In reality, a piston engine 
comprises a piston, valves and many other components; the fact that a piston is an 
element of a piston engine can be logically and semantically represented in OOP by 

20 two objects. 

OOP also allows creation of an object that "depends from" another object. If there 
are two objects, one representing a piston engine and the other representing a piston 
engine wherein the piston is made of ceramic, then the relationship between the two 

25 objects is not that of composition. A ceramic piston engine does not make up a 
piston engine. Rather it is merely one kind of piston engine that has one more 
limitation than the piston engine; its piston is made of ceramic. In this case, the 
object representing the ceramic piston engine is called a derived object, and it 
inherits all of the aspects of the object representing the piston engine and adds 

30 further limitation or detail to it. The object representing the ceramic piston engine 
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"depends from" the object representing the piston engine. The relationship between 
these objects is called inheritance. 

When the object or class representing the ceramic piston engine inherits all of the 
aspects of the objects representing the piston engine, it inherits the thermal 
characteristics of a standard piston defined in the piston engine class. However, the 
ceramic piston engine object overrides these ceramic specific thermal 
characteristics, which are typically different from those associated with a metal 
piston. It skips over the original and uses new functions related to ceramic pistons. 
Different kinds of piston engines have different characteristics, but may have the 
same underlying functions associated with it (e.g., how many pistons in the engine, 
ignition sequences, lubrication, etc.). To access each of these functions in any piston 
engine object, a programmer would call the same functions with the same names, 
but each type of piston engine may have different/overriding implementations of 
functions behind the same name. This ability to hide different implementations of a 
function behind the same name is called polymorphism and it greatly simplifies 
communication among objects. 

With the concepts of composition-relationship, encapsulation, inheritance and 
polymorphism, an object can represent just about anything in the real world. In fact, 
one's logical perception of the reality is the only limit on determining the kinds of 
things that can become objects in object-oriented software. Some typical categories 
are as follows: 

• Objects can represent physical objects, such as automobiles in a traffic-flow 
simulation, electrical components in a circuit-design program, countries in an 
economics model, or aircraft in an air-traffic-control system. 

• Objects can represent elements of the computer-user environment such as 
windows, menus or graphics objects. 

• An object can represent an inventory, such as a personnel file or a table of 
the latitudes and longitudes of cities. 
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• An object can represent user-defined data types such as time, angles, and 
complex numbers, or points on the plane. 

With this enormous capability of an object to represent just about any logically 
separable matters, OOP allows the software developer to design and implement a 
computer program that is a model of some aspects of reality, whether that reality is a 
physical entity, a process, a system, or a composition of matter. Since the object can 
represent anything, the software developer can create an object which can be used as 
a component in a larger software project in the future. 

If 90% of a new OOP software program consists of proven, existing components 
made from preexisting reusable objects, then only the remaining 10% of the new 
software project has to be written and tested from scratch. Since 90% already came 
from an inventory of extensively tested reusable objects, the potential domain from 
which an error could originate is 10% of the program. As a result, OOP enables 
software developers to build objects out of other, previously built objects. 

This process closely resembles complex machinery being built out of assemblies and 
sub-assemblies. OOP technology, therefore, makes software engineering more like 
hardware engineering in that software is built from existing components, which are 
available to the developer as objects. All this adds up to an improved quality of the 
software as well as an increased speed of its development. 

s 

Programming languages are beginning to fully support the OOP principles, such as 
encapsulation, inheritance, polymorphism, and composition-relationship. With the 
advent of the C++ language, many commercial software developers have embraced 
OOP. C++ is an OOP language that offers a fast, machine-executable code. 
Furthermore, C++ is suitable for both commercial-application and systems- 
programming projects. For now, C++ appears to be the most popular choice among 
many OOP programmers, but there is a host of other OOP languages, such as 
Smalltalk, Common Lisp Object System (CLOS), and Eiffel. Additionally, OOP 
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capabilities are being added to more traditional popular computer programming 
languages such as Pascal. 

The benefits of object classes can be summarized, as follows: 

• Objects and their corresponding classes break down complex programming 
problems into many smaller, simpler problems. 

• Encapsulation enforces data abstraction through the organization of data into 
small, independent objects that can communicate with each other. 
Encapsulation protects the data in an object from accidental damage, but 
allows other objects to interact with that data by calling the object's member 
functions and structures. 

• Subclassing and inheritance make it possible to extend and modify objects 
through deriving new kinds of objects from the standard classes available in 
the system. Thus, new capabilities are created without having to start from 
scratch. 

• Polymorphism and multiple inheritance make it possible for different 
programmers to mix and match characteristics of many different classes and 
create specialized objects that can still work with related objects in 
predictable ways. 

• Class hierarchies and containment hierarchies provide a flexible mechanism 
for modeling real-world objects and the relationships among them. 

• Libraries of reusable classes are useful in many situations, but they also have 
some limitations. For example: 

• Complexity. In a complex system, the class hierarchies for related classes 
can become extremely confusing, with many dozens or even hundreds of 
classes. 

• Flow of control. A program written with the aid of class libraries is still 
responsible for the flow of control (i.e., it must control the interactions 
among all the objects created from a particular library). The programmer has 
to decide which functions to call at what times for which kinds of objects. 
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• Duplication of effort. Although class libraries allow programmers to use and 
reuse many small pieces of code, each programmer puts those pieces 
together in a different way. Two different programmers can use the same set 
of class libraries to write two programs that do exactly the same thing but 
whose internal structure (i.e., design) may be quite different, depending on 
hundreds of small decisions each programmer makes along the way. 
Inevitably, similar pieces of code end up doing similar things in slightly 
different ways and do not work as well together as they should. 

Class libraries are very flexible. As programs grow more complex, more 
programmers are forced to reinvent basic solutions to basic problems over and over 
again. A relatively new extension of the class library concept is to have a 
framework of class libraries. This framework is more complex and consists of 
significant collections of collaborating classes that capture both the small scale 
patterns and major mechanisms that implement the common requirements and 
design in a specific application domain. They were first developed to free 
application programmers from the chores involved in displaying menus, windows, 
dialog boxes, and other standard user interface elements for personal computers. 

Frameworks also represent a change in the way programmers think about the 
interaction between the code they write and code written by others. In the early days 
of procedural programming, the programmer called libraries provided by the 
operating system to perform certain tasks, but basically the program executed down 
the page from start to finish, and the programmer was solely responsible for the flow 
of control. This was appropriate for printing out paychecks, calculating a 
mathematical table, or solving other problems with a program that executed in just 
one way. 

The development of graphical user interfaces began to turn this procedural 
programming arrangement inside out. These interfaces allow the user, rather than 
program logic, to drive the program and decide when certain actions should be 
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performed. Today, most personal computer software accomplishes this by means of 
an event loop which monitors the mouse, keyboard, and other sources of external 
events and calls the appropriate parts of the programmer's code according to actions 
that the user performs. The programmer no longer determines the order in which 
events occur. Instead, a program is divided into separate pieces that are called at 
unpredictable times and in an unpredictable order. By relinquishing control in this 
way to users, the developer creates a program that is much easier to use. 
Nevertheless, individual pieces of the program written by the developer still call 
libraries provided by the operating system to accomplish certain tasks, and the 
programmer must still determine the flow of control within each piece after it's 
called by the event loop. Application code still "sits on top of the system. 

Even event loop programs require programmers to write a lot of code that should not 
need to be written separately for every application. The concept of an application 
framework carries the event loop concept further. Instead of dealing with all the 
nuts and bolts of constructing basic menus, windows, and dialog boxes and then 
making these things all work together, programmers using application frameworks 
start with working application code and basic user interface elements in place. 
Subsequently, they build from there by replacing some of the generic capabilities of 
the framework with the specific capabilities of the intended application. 

Application frameworks reduce the total amount of code that a programmer has to 
write from scratch. However, because the framework is really a generic application 
that displays windows, supports copy and paste, and so on, the programmer can also 
relinquish control to a greater degree than event loop programs permit. The 
framework code takes care of almost all event handling and flow of control, and the 
programmer's code is called only when the framework needs it (e.g., to create or 
manipulate a proprietary data structure). 

A programmer writing a framework program not only relinquishes control to the 
user (as is also true for event loop programs), but also relinquishes the detailed flow 
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of control within the program to the framework. This approach allows the creation 
of more complex systems that work together in interesting ways, as opposed to 
isolated programs, having custom code, being created over and over again for 
similar problems. 

Thus, as is explained above, a framework basically is a collection of cooperating 
classes that make up a reusable design solution for a given problem domain. It 
typically includes objects that provide default behavior (e.g., for menus and 
windows), and programmers use it by inheriting some of that default behavior and 
overriding other behavior so that the framework calls application code at the 
appropriate times. 

There are three main differences between frameworks and class libraries: 

• Behavior versus protocol. Class libraries are essentially collections of 
behaviors that you can call when you want those individual behaviors in your 
program. A framework, on the other hand, provides not only behavior but 
also the protocol or set of rules that govern the ways in which behaviors can 
be combined, including rules for what a programmer is supposed to provide 
versus what the framework provides. 

• Call versus override. With a class library, the code the programmer 
instantiates objects and calls their member functions. It's possible to 
instantiate and call objects in the same way with a framework (i.e., to treat 
the framework as a class library), but to take full advantage of a framework's 
reusable design, a programmer typically writes code that overrides and is 
called by the framework. The framework manages the flow of control 
among its objects. Writing a program involves dividing responsibilities 
among the various pieces of software that are called by the framework rather 
than specifying how the different pieces should work together. 

• Implementation versus design. With class libraries, programmers reuse only 
implementations, whereas with frameworks, they reuse design. A 
framework embodies the way a family of related programs or pieces of 
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software work. It represents a generic design solution that can be adapted to 
a variety of specific problems in a given domain. For example, a single 
framework can embody the way a user interface works, even though two 
different user interfaces created with the same framework might solve quite 
different interface problems. 

Thus, through the development of frameworks for solutions to various problems and 
programming tasks, significant reductions in the design and development effort for 
software can be achieved. A preferred embodiment of the invention utilizes 
HyperText Markup Language (HTML) to implement documents on the Internet 
together with a general-purpose secure communication protocol for a transport 
medium between the client and the Newco. HTTP or other protocols could be 
readily substituted for HTML without undue experimentation. Information on these 
products is available in T. Berners-Lee, D. Connoly, "RFC 1866: Hypertext Markup 
Language - 2.0" (Nov. 1995); and R. Fielding, H, Frystyk, T. Berners-Lee, J. Gettys 
and J.C. Mogul, "Hypertext Transfer Protocol » HTTP/1 .1 : HTTP Working Group 
Internet Draft" (May 2, 1996). HTML is a simple data format used to create 
hypertext documents that are portable from one platform to another. HTML 
documents are SGML documents with generic semantics that are appropriate for 
representing information from a wide range of domains. HTML has been in use by 
the World-Wide Web global information initiative since 1990. HTML is an 
application of ISO Standard 8879; 1986 Information Processing Text and Office 
Systems; Standard Generalized Markup Language (SGML). 

To date, Web development tools have been limited in their ability to create dynamic 
Web applications which span from client to server and interoperate with existing 
computing resources. Until recently, HTML has been the dominant technology used 
in development of Web-based solutions. However, HTML has proven to be 
inadequate in the following areas: 

• Poor performance; 

• Restricted user interface capabilities; 
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• Can only produce static Web pages; 

• Lack of interoperability with existing applications and data; and 

• Inability to scale. 

5 Sun Microsystem's Java language solves many of the client-side problems by: 

• Improving performance on the client side; 

• Enabling the creation of dynamic, real-time Web applications; and 

• Providing the ability to create a wide variety of user interface components. 

10 With Java, developers can create robust User Interface (UI) components. Custom 
"widgets" (e.g., real-time stock tickers, animated icons, etc.) can be created, and 
client-side performance is improved. Unlike HTML, Java supports the notion of 
client-side validation, offloading appropriate processing onto the client for improved 
performance. Dynamic, real-time Web pages can be created. Using the above- 

15 mentioned custom UI components, dynamic Web pages can also be created. 

Sun's Java language has emerged as an industry-recQgnized language for 
"programming the Internet." Sun defines Java as: "a simple, object-oriented, 
distributed, interpreted, robust, secure, architecture-neutral, portable, high- 

20 performance, multithreaded, dynamic, buzzword-compliant, general-purpose 

programming language. Java supports programming for the Internet in the form of 
platform-independent Java applets." Java applets are small, specialized applications 
that comply with Sun's Java Application Programming Interface (API) allowing 
developers to add "interactive content" to Web documents (e.g., simple animations, 

25 page adornments, basic games, etc.). Applets execute within a Java-compatible 

browser (e.g., Netscape Navigator) by copying code from the server to client. From 
a language standpoint, Java's core feature set is based on C++. Sun's Java literature 
states that Java is basically, "C++ with extensions from Objective C for more 
dynamic method resolution." 
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Another technology that provides similar function to JAVA is provided by 
Microsoft and ActiveX Technologies, to give developers and Web designers 
wherewithal to build dynamic content for the Internet and personal computers. 
ActiveX includes tools for developing animation, 3-D virtual reality, video and other 
5 multimedia content. The tools use Internet standards, work on multiple platforms, 
and are being supported by over 100 companies. The group's building blocks are 
called ActiveX Controls, small, fast components that enable developers to embed 
parts of software in hypertext markup language (HTML) pages. ActiveX Controls 
work with a variety of programming languages including Microsoft Visual C++, 

10 Borland Delphi, Microsoft Visual Basic programming system and, in the future, 
Microsoft's development tool for Java, code named "Jakarta." ActiveX 
Technologies also includes ActiveX Server Framework, allowing developers to 
create server applications. One of ordinary skill in the art readily recognizes that 
ActiveX could be substituted for JAVA without undue experimentation to practice 

15 the invention. 



Figure 5 illustrates a process 500 for affording a virtual trade financial framework. 
First, in operation 502, an agreement is established between a buyer and a seller for 
trading purposes. In operation 504, initiation and payment documents are received 

20 utilizing a network. Also received, in operation 506, are secondary documents such 
as an insurance certificate, inspection certificate, certificate of origin, 
invoice/declaration, counselor's invoice, sanction and boycott declaration, packing 
list, weight list, lab test report, and/or beneficiary certificate. Thereafter, the 
secondary documents are sent to a bank to be checked in operation 508. When 

25 operating, the buyer accesses the secondary documents via the bank. Figure 6 
illustrates a variation of the process of Figure 5. 



In one embodiment of the present invention, the secondary documents are received 
via a facsimile transmission. Further, the initiation and payment documents may 
30 include a combined purchase order proforma invoice. As an option, the secondary 
documents may be stored, indexed and matched. 
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In another embodiment of the present invention, the secondary documents include 
an insurance certificate, inspection certificate, certificate of origin, 
invoice/declaration, counselor's invoice, sanction and boycott declaration, packing 
list, weight list, lab test report, and beneficiary certificate. 

Figure 7 illustrates operation of a virtual trade financial framework 700. At 702, a 
buyer 704 applies for a line of credit through the buyer's bank 706. The buyer and 
seller 708 get together and agree to trade on VTrade at 710. At 712, the buyer 
creates an electronic sales agreement. At 714, the buyer and seller agree on the sales 
agreement. VTrade stores transmitted documents, such as emails, presentation, and 
facsimiles, at 716. At 718, VTrade facilitates payment release through a payment 
network. The buyer's bank consolidates a bill and bills the buyer at 720. 

Figure 8 depicts optional enhancements that may be offered and performed during 
operation of the virtual trade financial framework 700 of Figure 7. Such 
enhancements can include allowing online auctions 800, integration to third parties 
802, and linkages to online procurement sites 804. Online credit applications 806 
may be permitted, as may integration to other payment network(s) 808. 

Figure 9 illustrates several areas which VTrade will fulfill in the eCommerce value 
chain. Such areas include provider access 900, customer service 902, market 
making 904, buyer agency 906, customer access 908, risk management 910, and 
fulfillment 912. 

Figure 10 depicts a process flow of the VTrade framework. At 1000, the buyer 
creates an electronic purchase order, which is used to create a combined purchase 
order proforma invoice. The buyer and seller approve the combined purchase order 
proforma invoice at 1002. As an option, the seller may contract for carriers, 
providers, etc. for aspects relating to the goods being traded. At 1006, the trade 
documents are sent to VTrade, which are then stored and indexed at 1008. A check 
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of the documents may also be made to ensure that all necessary documentation has 
arrived, etc. At 1010, the buyer can check the documents online. The buyer's bank 
pays for the goods over an interface with VTrade at 1012 and sends a consolidated 
statement to the buyer at 1014, after which the buyer pays the bank at 1016. 

5 

Figure 1 1 illustrates a process for application of a line of credit and access to the 
VTrade system for a buyer. In operation 1100, the buyer's (applicant) application 
for credit is sent to the bank.^ In operation 1102, the application is processed at the 
credit provider (bank). The new credit and VTrade enrollment information is 
10 registered and sent to the buyer in operations 1104 and 1106, respectively. In 
operation 1108, a VTrade card is sent to the buyer, as is acknowledgement of 
enrollment and receipt of the credit information in operation 1110. 

Figure 12 illustrates a process for application for access to the VTrade system by a 
15 seller/merchant 1200. Numbers 1-7 enumeration the steps of the process. 

Figure 13 is a flowchart of a process 1300 for initiating bidding in a virtual trade 
financial environment. In operation 1302, a form is submitted to a plurality of 
buyers providing details on products or services available from a plurality of sellers. 

20 This is to prompt the submission of bids on the products or services. Such forms 
can include paper documents, facsimiles, emails, etc. The bids are then received 
from the buyers 1304 utilizing a network. Thereafter, in operation 1306, the bids are 
categorized based on a predetermined criteria. The categorized bids are 
subsequently sent to the sellers in operation 1308 utilizing the network. In operation 

25 1310, offers are received from the sellers in response to the bids utilizing the 
network. The offers are displayed to the buyers in operation 1312 and the 
transactions between the buyers and the sellers are closed in operation 1314. 
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In one embodiment of the present invention, an identity of the buyers is 
authenticated prior to submitting the form thereto. The identity is authenticated by 
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requiring the submission of an identifier and a password. As an option, the step of 
categorizing the bids may include ranking or segmenting the bids. 

In another embodiment of the present invention, the criteria may include a 
geography and/or product category. Further, the bids and offers may be displayed 
on a site on the network. 

Figure 14 expands on the bidding process of the VTrade system discusses above 
with reference to Figure 13. In operation 1400, VTrade bid forms are sent to buyers 
to invite bids. The bids received from the buyers are captured and sorted in 
operation 1402. In operation 1404, interested sellers are permitted to receive the bid 
forms online and view them and then, in operation 1406, are allowed to submit 
competitive bid offers. These bid offers are captured in operation 1408 and sent to 
the appropriate buyers. Operations 1402 through 1408 can be repeated until a buyer 
or seller accepts a bid. After the buyers review the sellers' offers, interested buyers' 
manifestations of intent to transact are captured and transmitted to the sellers in 
operations 1410 and 1412, which closes the bidding. 

Figure 15 is a flowchart illustrating a process 1500 for initiating a transaction in a 
virtual trade financial framework. In operation 1502, an agreement between a buyer 
and a seller is established for trading purposes. A form is then received in operation 
1504 indicating terms or conditions of the buyer. In response to the receipt of the 
form, a credit of the buyer is checked using a third party in operation 1506. The 
credit check is performed based on the form. In operation 1508, the seller is 
provided with the form and an indication as to the sufficiency of the credit of the 
buyer. A response to the form and indication is subsequently received from the seller 
in operation 1510. Such response of the seller is forwarded to the buyer in operation 
1512. 

In one embodiment, the agreement between the buyer and the seller may include 
payment terms. Further, an identity of the buyer may be authenticated prior to 
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receiving the form. As an option, the identity may be authenticated by requiring the 
submission of an identifier and a password. 

In another embodiment, the seller may be requested to become a registered member 
of the framework. As an option, the agreement may be finalized after forwarding 
the response of the seller to the buyer. 

Figure 16 is a flow diagram which expands on the process of Figure 15. In 
operation 1600, it is determined that a buyer and seller have agreed to transact on 
VTrade. In operation 1602, an invoice, in this example a purchase order proforma 
invoice (POPI), is received from the buyer and authenticated before being sent to the 
seller. See the discussion of Figures v23 and 21 below for a description of the POPI. 
A request for a credit check is sent to the bank (or credit provider) in operation 1604. 
The buyer's credit line is also earmarked in operation 1606 to indicate the amount of 
the purchase order to prevent the buyer from exceeding the maximum amount of 
credit. In operation 1608, the seller is alerted to start negotiating on the invoice. 
The initiation of negotiation is confirmed in operation 1610. The buyer is alerted 
that the seller acknowledges the transaction in operation 1612. In operation 1614 
and 1616, a negotiation about the invoice is facilitated and, when negotiations cease, 
the invoice is finalized. 

Figure 17 is a flow diagram for initiation of a transaction between a buyer 1700 and 
seller 1702 using combined purchase order proforma invoice submission. Numerals 
1-8 set forth the order of the process. 

Figure 18 illustrates a process for a payment transaction during a trade. In operation 
1800, trade documents are received from the seller. In operation 1802, goods are 
shipped for the seller. The documents from the seller are stored and indexed online 
and made available for the buyer to view in operation 1804. Upon receiving a 
request from the buyer, the documents are displayed to the buyer in operation 1806. 
Payment authorization is also received from the buyer, upon which, in operation 
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1808, a diligence check is made or requested in order to initiate payment. The 
amount of the payment is calculated in operation 1810. In operation 1812, proceeds 
from a credit drawdown are sent to the seller. All trade documents are released to 
the buyer in operation 1814 and the buyer is allowed to take delivery of the goods in 
operation 1816. 

Figure 19 illustrates a payment process when there is no disagreement on the terms 
of the documents. Reference numerals 1-7 provide the order of the steps of the 
process. Figure 20 depicts a payment process when there is a disagreement on the 
terms of the documents. Reference numerals 1-7 provide the order of the steps of 
the process. Figure 21 depicts a process for account settlement and/or financing for 
a buyer (importer) in the VTrade system. Reference numerals 1-5 provide the order 
of the steps of the process. Figure 22 illustrates a payment process when a direct 
transfer of funds is available. Numbers 1-6 set forth the order of the steps of the 
process. 

Figure 23 is a flowchart illustrating a process 2300 for completing a purchase 
order/invoice. In operation 2302, an initial version of a form is received from the 
buyer indicating at least one requirement for the seller to fulfill. The seller is then 
allowed to amend the form in operation 2304 thus generating a revision of the form. 
Such version of the form that is received by the seller is then saved in operation 
2306. Likewise, the buyer is then allowed to amend the form in operation 2308 thus 
generating a revision of the form. Such version of the form that is received by the 
buyer is then saved in operation 2310. In operation, the various versions of the form 
are made available for editing and use until there are no further amendments, and the 
purchase order/invoice is complete. See operations 2312,2314. 

In one embodiment, the amendments include changing terms of the form. Further, 
the form may include a combined purchase order proforma invoice. As an option, 
the form may include a first section indicating a plurality of terms, a second section 
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indicating requirements of the buyers with respect to the terms, and a third section 
indicating requirements of the sellers with respect to the terms. 



In another embodiment of the present invention, the form is automatically sent to a 
database utilizing a network in response to the buyer and seller signing the form. As 
an option, commercial shipping documents may be created utilizing input from the 
seller. 

Figures 24 A and 24B illustrate an illustrative Purchase Order Performa Invoice 
(POPI) v2300. The Purchase Order Proforma Invoice allows a buyer to submit an 
application to initiate a transaction in VTrade electronically on VTrade Web. The 
Buyer indicates the performance by seller or requirement for seller to fulfill via 
POPI. The buyer submits the POPI to VTrade after completing all 
terms/performance required of the seller. Buyer's bank checks and earmarks 
buyer's VTrade line of credit (LOG). Once the LOC is earmarked by the bank, 
confirmation is sent to seller by VTrade. A confirmed/interested seller will 
negotiate sales/purchase terms with buyer using the POPI. The seller will indicate 
fulfillment of the buyer's requirements on a Combined Purchase Order Proforma 
Invoice. 



If the seller cannot fulfill the buyer's requirement, the buyer and seller will amend 
the POPI until agreeable terms are achieved. The buyer and seller can submit each 
amendment on POPI via the submit pushbutton v2302,v2304. Each amendment by 
trading parties on POPI will be reflected as a new version. The VTrade Web allows 
old versions of amendments to be stored and viewed. Once the POPI is finalized, 
the buyer and seller signs agreement on overall terms and conditions of POPI which 
automatically triggers POPI to be sent to VTrade. The seller then proceeds to 
prepare commercial/trade documents for payment. 

Figure 25 depicts a combined Purchase Order Performa Invoice 2500. The 
Combined Purchase Order Proforma Invoice allows buyer to submit application to 




initiate transaction in VTrade over VTrade Web. The buyer indicates a requirement 
for the seller to fulfill on the Combined Purchase Order Pro forma Invoice. The 
buyer submits Combined Purchase Order Proforma Invoice to VTrade after 
completing requirements. VTrade checks and earmarks buyer's line of credit. Once 
the line is earmarked by bank, confirmation is sent to the seller. The seller will 
indicate fulfillment of the buyer's requirements on the Combined Purchase Order 
Proforma Invoice. 

If the seller cannot fulfill the buyer's requirement, the buyer and seller will amend 
the Combined Purchase Order Proforma Invoice until agreeable terms are achieved. 
Each amendment by the trading parties on Combined Purchase Order Proforma 
Invoice will be reflected as a new version. VTrade Web allows old versions of 
amendments to be viewed. Once agreement is reached on the Combined Purchase 
Order Proforma Invoice, the buyer and seller sign the agreement on overall terms 
and conditions of the Purchase Order Proforma Invoice which automatically triggers 
a purchase order to be sent to VTrade. The seller then proceeds to prepare 
commercial shipping documents (option of using VTrade Electronic Document 
Creator). 

Figure 26 is a flowchart depicting a process 2600 for creating a finalized document 
relating to a transaction. In operation 2602, a buyer and a seller are allowed to 
negotiate terms of an agreement. A form detailing the negotiated terms is displayed 
in operation 2604. The buyer and seller may digitally sign the form in operation 
2606. Documents supporting the form are organized and stored in operation 2608. 
In operation 2610, payment to the seller is initiated only after receiving a 
verification of credit of the buyer. 

In one embodiment of the present invention, the form may include a first section 
indicating the terms, a second section for allowing the buyer to sign off on the terms, 
and a third section for allowing the buyer to sign off on the terms. As an option, the 
form may be displayed after the negotiation of the terms in response to the selection 
of an icon. 
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In another embodiment, the documents supporting the form may be displayed. As 
an option, the form may be automatically sent to a database utilizing a network in 
response to the buyer and seller finishing the signing of the form. Further, the 
payment may be completed only after checking the form and the receipt of payment 
authorization from the buyer. 

Figure 27 illustrates the Main Menu Page of an electronic document checklist 2700 
which may be used during the process of Figure 26. The Electronic Document 
Creator (Main Menu) is the front page for the VTrade Electronic Document Creator. 
It is essentially a deal sheet for the buyer and seller to sign on once agreement is 
reached on all documents. The buyer and seller negotiate on terms of a transaction 
using the document creator. By pressing on the icon 2702 next to the documents 
indicated, buyer/seller is linked to the next layer which is the Electronic Document 
Creator (Document Page). Once there is agreement on the terms of a particular 
document (refer Document Creator), buyer and seller 'digitally signs' by selecting 
an icon 2704 next to the related document on the main menu page. The Document 
Creator (Main Menu) also help track receipt of other related physical documents 
outside VTrade. Scan or 'mirror copies' of these documents can be viewed but they 
are not checked by VTrade Once agreement is reached on all documents between 
buyer and seller, both sign an agreement on overall terms and conditions of the 
Document Creator before submission to VTrade. The VTrade Enterprise digitally 
checks that all electronic documents submitted are collected and waits for payment 
authorization from the bank/buyer before using the payment interface to contact 
Visanet for payment to seller.Figure 28 is a flowchart illustrating a process 2800 for 
creating a financial transaction-related document. In operation 2802, a buyer is 
allowed to select among a plurality of documents associated with a proposed 
transaction. In operation 2804, the buyer is permitted to indicate requirements of 
trade terms relating to the selected documents. A seller may agree or amend the 
terms on an electronic document platform in operation 2806. Upon each 
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amendment, a new version of a form delineating the trade terms is generated in 
operation 2808. In operation 2810, each of the versions may be viewed. 

In one embodiment of the present invention, the trade terms may include shipping 
5 related terms. As an option, the terms of the form may be filtered, so that the form 
may be outputted with only the terms included after filtering for various purposes. 
As an option, standard documents associated with the form may be generated to be 
used with the form during the transaction. 

10 In another embodiment, the form may include a first section indicating a plurality of 
shipping terms, a second section indicating requirements of the buyers with respect 
to the terms, and a third section indicating fulfillment of the terms by the seller. 



Figure 29 illustrates a Document Page 2900 of an electronic document creator. The 
15 Electronic Document Creator provides the seller with the option of creating 

commercial shipping documents electronically. The document creator allows buyer 
to indicate the requirements of the trade terms and seller to agree or amend the terms 
on an electronic document platform. Both buyer and seller can access Document 
O Page from the Menu page. The buyer and seller will negotiate only on the 

20 documents selected by the buyer on the VTrade Document Creator (Main Menu). 
The VTrade document creator will have defined parameters and structured format 
within which only the most common trade requirements and information are 
included. Each amendment for the document creator will be captured on a new 
version. Document Creator allows for old versions to be viewed. Once terms and 
25 conditions is agreed on the document-level, buyer and seller will sign-off on the icon 
next to the respective document on the Document Creator (Main Menu) page. The 
VTrade Document Creator will allow creation of standardized documents (which 
could mirror the Generic Electronic Credit Instrument guideline currently being 
developed by the ICC Working Party). 
30 Figure 30 depicts an electronic Documents Checklist 3000. The Document 

Checklist is an online document checking facilitation list which allows the buyer to 
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view and check the trade documents submitted by seller on-line via the VTrade 
Web. By pressing on the icon 3002 next to the documents indicated, the buyer is 
linked to the next layer which is the stored documents submitted to VTrade. Once 
an agreement is reached on all documents, the buyer signs agreement on overall 
terms and conditions of Document Checklist. If discrepancies are found by buyer, it 
is to be noted on the discrepancies column 3004 next to the respective documents in 
which the corresponding discrepancies are found. The buyer will sign on the 
checklist once all documents are checked. 

Figure 31 illustrates a VTrade compliance engine 3100. The compliance engine has 
a fully-automated compliance checking capability built into the VTrade Web 
solution, which comprises the VTrade Web front page, the front-end Cofribined 
Purchase Order Proforma Invoice and the Electronic Document Creator, all linked to 
bank and customer's back-end processing systems. 

An automatic check is triggered once Seller and Buyer signs off digitally on Main 
Menu of Document Creator for overall agreement (all terms of documents required 
by Buyer is agreed, including physical documents checked outside of VTrade). 
Two types of automated compliance check are performed simultaneously: 

i) Combined Purchase Order Proforma Invoice 3102 against 
transportation document (Bill of Lading, Airwaybill, Truck BL ) 

ii) Cross commercial shipping documents check 

The compliance checking is performed through data validation on defined 
parameters of structured formats for text. Once the compliance engine finds all 
structured fields/tag are in compliance (clean), an automatic signal is sent to the 
bank/buyer for payment authorization. When payment authorization is received, the 
signal will prompt Visanet to credit the seller's account. Anytime the value of the 
data falls outside the parameter of the structured field, it is rejected as 'discrepant.' 
The rejection will be automatically sent and highlighted to both buyer and seller 
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electronically. Only upon the completion of all checks of structured fields will 
discrepancy signal be sent to buyer and seller, who will renegotiate on the 
highlighted discrepancies on VTrade Web's electronic platform 

Figure 32 illustrates a first option of documentary compliance in a VTrade system. 
Here, only VTrade 3200 checks the electronic documents. (Assume only Combined 
Purchase Order Proforma Invoice and transportation documents require checking.) 
Figure 33 illustrates a second option of documentary compliance in which the Bank 
3300 checks physical documents while VTrade 3302 checks electronic documents. 
Figure 34 illustrates a third option of documentary compliance in which the buyer 
3400 checks physical documents while VTrade 3402 checks electronic documents. 
Figure 35 illustrates a general architecture of the VTrade system, including a buyer 
station 3500, a seller station 3502, a processing hub 3504, and a credit provider 
system 3506. Figure 36 illustrates an exemplary technical framework for a VTrade 
system. As shown, the VTrade enterprise 3600 is connected to the external world 
3602, which is where the buyers and sellers are located. The enterprise is also 
connected to the payment system 3604. 

Figure 37 illustrates several potential security threats, including viruses 3700, and 
internal attacks 3702. Figure 38 illustrates security features which may be used with 
the technical framework of the VTrade system. Such features include encryption 
3800, authentication 3802, and firewalls 3804. Figure 39 illustrates several security 
principles 3900 and the services 3902, 3904, 3906 which provide them. 

A VTrade system should provide the following security features: 

• Authentication - No one can pretend to be someone else 

• Privacy - Only authorised people and systems can access information. This 
includes privacy both during transport on the network and against 
unauthorised insiders 
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• Non-repudiation - Users are prevented from denying that they authorised 
the transaction 

• Transaction Integrity - This ensures that stored or transmitted information 
in VTrade is unaltered 

• Non-refutability - This ensures that users can verify that the actual exchange 
took place by providing a digital receipt or similar proof of payment 



• Time stamping - This is especially important for responding to duties with a 
actionable deadline 

Security components: 

• Signature/validation: allow the sender to sign its message before sending 
them and to validate its signature 

• Encryption/decryption of on-line transaction : allow the sender to encrypt the 
messages he wants to send in order to keep its content secret 

• Authentication: confirming the identity of parties involved in the transaction 



• Firewall and network security : establishing a barrier between the VTrade 
corporate network (secure network) and the external Internet (untrusted 
network). Only VTrade Members is granted access from outside based on 
user names and passwords, Internet IP address, or domain name 

Integrity: 

• confirmation that the content of a message has not been altered 
Non-repudiation : 



• the signer cannot deny the signing of the message 
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Confidentiality: 

• relevant information is kept secret, only the receiver is able to decode the 
encrypted message in the original plain text 

Interoperability with other eCommerce Operating Models 

• Participation in a world-wide certification hierarchy 

• Cross certification with other certification authorities 

• Security deployment on the Internet 

• Exchange of third party services on transactions 

VTrade should operate under some group of recognized rules, preferably rules that 
are enforceable in foreign countries. Figure 40 illustrates an embodiment of the 
present invention in which VTrade operates under applicable Visa Card and 
international commerce rules 4000,4002, with an avenue for dispute resolution via 
the ICC international court for arbitration. 

Figure 41 illustrates a legal framework 4100 when the rules are set by the VTrade 
Enterprise. These rules may apply to both the buyer and seller. All legal contracts 
outside the VTrade rules should also be established between parties. 

Figure 42 depicts the legal responsibilities of VTrade 4200 and the Bank 4202. 
Figure 43 illustrates the legal responsibilities of the buyer 4300 and seller 4302. 

VTrade may provide a forum for buyers and sellers to settle unresolved disputes 
through VTrade Rules. The handling of disputes under Traditional Trade Finance 
can be governed by rules in UCP 500 and URC 522 issued by the International 
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Chamber of Commerce (ICC). Both UCP 500 and URC 522 contain a complex set 
of rules relating the documents in International Trade. 

VTrade, may have its own set of rules which govern the underlying goods similar to 
how credit card rules for retail transactions. In traditional trade finance, disputes can 
be settled bringing the case to the ICC International Court of Arbitration or to the 
courts under the normal law of contracts. Similarly, VTrade can provide a similar 
avenue of resolving disputes under VTrade rules. 

Under traditional Trade Finance, the process of refusal of acceptance occurs when 
the importer refuses acceptance of the document giving him rights to the title of the 
goods. This can happen under two different situations: 

(1) Where the LC is confirmed by the exporter's bank The confirming bank will 
pay the exporter as it had confirmed that the documents were in order. The 
confirming bank will then settle the disputes with the importer through the issuing 
bank. Failing which, the confirming bank will take the case to either the 
International Court of Arbitration or the courts. 

(2) Where the LC is not confirmed. The exporter will seek redress from the issuing 
bank. Failing which the exporter will take the case to the International Court of 
Arbitration or the court with the issuing bank and the importer as defendants. 
Under VTrade, the process of refusal of acceptance occurs when the importer 
refuses acceptance of the goods. The exporter will seek redress from the Credit 
Provider who provided the guarantee that payment will made when the goods are 
shipped according to the purchase order. The exporter can bring the case to the 
International Court of Arbitration to decide whether the exporter had met the terms 
of the purchase order. If the International Court of Arbitration holds judgment for 
the exporter, the Credit Provider will make payment to the exporter and seek 
recourse from the importer. 

Figures 44-52 depict an illustrative process flow for operation of the VTrade system 
with the steps organized in columns associated with the party performing or 
directing the step, i.e., a buyer 4400, buyer's bank 4402, VTrade 4404, seller's bank 
4406, and a seller 4408. Figure 44 shows a process for credit application and access, 
which continues at A in Figure 45. Figure 46 depicts a process for initiation of 
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bidding. Figures 47 and 48 illustrate a process for submission of a VTrade POP! 
Figure 49 depicts a process for negotiation and finalization of the POPI. Figures 50 
and 51 illustrate a process for facilitation of document checking during payment. 
Figure 52 illustrates a process for account billing and VTrade account management. 

As such, the embodiments set forth above allow business-to-business commerce and 
eMarkets. Several factors that are driving the adoption of business to business 
commerce are: 

Increasing Competition and Globalization 

• Global search for inexpensive goods and services extends beyond traditional 
boundaries 

• Internet enables procurement on global scaleGrowing Interactivity 

• Internet spurs growing interactivity among companies and their trading 
partners 

• Access to, and free flow of, information allows more informed 
decisionsFinancial Opportunity 

• Growing trade creates lucrative opportunity for eMarket makers and 
infrastructure enablers 

Efficiencies and Cost Savings 

• Online markets reduce transaction times and costs 

• Reduces "paid/get paid" cycle time 
Extended Market and Customer Reach 

• Access to buyers/sellers outside traditional trading circles and geographic 



Real-time Solutions 

• Online markets mimic true supply and demand for goods/services 

• Allows for dynamic, active management of business needs and resources 
Regulatory and Taxation Issues 



reach 
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• Markets are currently not heavily regulated or taxed by the federal 
government 

eMarketplaces offer buyers and sellers a new way to locate, engage, and transact 
online as traditional trading practices give way to new business models. Comparing 
eMarketplaces to traditional methods: 

eMarketplacesRestrictive vendor/supplier relationships 

• Maintain (or even shrinks) trading base 

• Focuses on historical experience 

• Limited to physical reach of supply chain and partners 

• Drive out proprietary supply chain inefficiencies 

• Drive price transparency and product standardization with exclusive trading 
partners 

• Exciting methods are mostly virtualization of traditional practices 

• Examples 

o Extranets 

o VANs (Value-added Networks) 
o EDI 

o Intermediaries (middlemen) 
Traditional MethodsBring together large numbers of buyers and sellers 

• Expand current trading base 

• Identify new markets for products 

• Cross/expand geographic and supply chain boundaries 

• Drive out market and industry wide inefficiencies 

• Drive price transparency and product standardization 

• Force new business models on the Web 

• Examples 

o Aggregators 
o Auctions 
o Exchanges 
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As shown in Figure 53, eMarketplaces can take three basic forms which intend to 
serve different market functions. These forms are: 

Aggregator 5300: A one-stop shopping venue. It streamlines purchasing by 
concentrating many product catalogs for buyer groups 

o Examples: Arbinet, Chemdex, MetalSite, NetBuy, PlasticsNet, 
ProcurementNet, TPN Register 

o "Can help me procure supplies at the lowest price" 

Auction 5302: A mechanism for liquidating surplus at best possible prices. It 
enables a wide range of potential buyers to bid competitively for products at below 
market prices. Reverse auctions (Bids) can also exist where buyers post or submit 
product needs and sellers bid for that sale 

o Examples: iMark, Fas tP arts, Inventory Locator Service, Manheim 
Online, ONSALE 

o "Can help me unload excess inventory at the best price" 
Exchanges 5304: An industry spot market for commodity-like products where 
price and quality are known between counterparties. It fills last minute needs for a 
small group of industry players with preexisting trading relationships 

o Examples: Altra Energy, Marex, QuickTrade, RateXchange, 
ChemConnect 



o "Can help me meet immediate needs in commoditized products' 
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The three emerging online marketplaces serve the basic functions of bringing buyers 
and sellers together online to easily exchange value, provide content, and form a 
community. As shown in Figure 54, these three marketplaces may be brought 
together to create an eMarketplace 5400. 

eMarketplaces can target either vertical market segments or horizontal market 
needs. 

Vertical 

• Description 

o Provide deep industry-specific content 

o Provide domain-specific relationships and contacts 

o Community focus oriented 

• Characteristics 

o Usually founded or backed by experienced industry personnel 
o Usually found in inefficient supply chains where many intermediaries 
exist 

o Early movers win as key suppliers are locked up early 
o Offer discussion forums and chat rooms 
o CattleOfferings.com (agriculture) 

Horizontal 

• Description 

o Spans across industry segments 
o Product focus orientation 

• Characteristics 

o Created by individuals with deep process knowledge or work-flow 

automation experience 
o Multiple product offerings 

o Usually found where high degrees of process standardization has 
occurred 

o Have diverse revenue sources and opportunities 
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The present invention is preferably practice in the context of a vertical market. 
Players with common needs will naturally look to deep vertical ^Marketplaces that 
cater to their specific needs. Therefore, horizontal hubs will be challenged to 
directly provide members with targeted industry knowledge and focused offerings. 
Further, fast movers will lock up key suppliers early making room in many market 
segments for only one player 

Characteristics of a dynamic eMarketplace include: 

• Liquid market 

• Transparent pricing 

• Detailed product information 

• Efficient, cost effective transaction capability 

• Information on members and counterparties 

• Clear and detailed rules and policies 

• Transactions initiated and consummated online 

As shown in Figure 55, an eMarket 5500 is supported by a technical infrastructure 
5502. To reach their potential, electronic markets must offer key capabilities that 
span from "making the market" to supporting the infrastructure. Figure 56 is a table 
setting forth descriptions of elements of the infrastructure including 
software/solutions 5600, IT 5602, fulfillment 5604, and financial services/risk 
management 5606. 

In addition to having attractive forums of exchange, electronic exchanges must also 
provide content and support the creation of communities. 

Content includes developing information which allows users to develop a strong 
understanding of what they're trading and with whom. Examples include historical 
price/volume data, product/service information, and buyer/seller credit ratings. 
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Commnnity includes providing information about related subject areas to members 
and allow them to exchange experiences. Examples include chat room, industry 
news, how-to 's, and community contacts 

Commerce includes creating a regulated forum for trade. Examples include 
open/closed trading rooms, multi-dimensional tradeoffs (price/time), and real-time 
order matching or auction. 

Electronic exchanges must also provide support services to facilitate trading. These 
are preferably part of the infrastructure. 

Several needs should be addressed in order to offer a complete eMarketplace. 
Figure 57 is a table setting forth a process to create solutions to specific needs during 
a buy and sell process. In operation 5700, the needs of the buyer and seller are 
identified and evaluated. In operation 5702, options are weighed. Negotiation and 
contract trading are allowed in operation 5704. Finally, a settlement is managed in 
operation 5706. 

Figure 58 illustrates another embodiment of the process for creating solutions to 
specific needs during a buy and sell process. In operation 5800, the needs of the 
buyer and seller are identified and evaluated. In operation 5802, options are 
weighed. Negotiation and contract trading are allowed in operation 5804. Finally, a 
settlement is managed in operation 5806. 

One embodiment of the present invention offers an integrated package of eEnabled 
financial services products in one or more of the five categories shown in Figure 59. 
These categories are: reputation assessment 5900, financing 5902, risk management 
5904, ePayments 5906, and information 5908. 

Figure 60 illustrates a TradeDirect system 6000 in accordance with one embodiment 
of the present invention. TradeDirect includes an infrastructure 6002 which can be 
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utilized by any number of business to business eMarketplaces. TradeDirect also 
provides online counterparty reputation assessment tools, financing, risk 
management tools, an ePayments facility, and information sources. TradeDirect 
automates research, contracting, and fulfillment in business to business 
eMarketplaces. 

Figure 61 illustrates how TradeDirect may connect to outside firms to provide a 
wide breadth of services, such as those found in Figure 62. Referring to Figure 61, 
TradeDirect 6100 is connected to a plurality of eMarkets 6102, and may be 
connected to a payments network 6104, credit rating agency 6106, and a technology 
enabler6108. 

TradeDirect should offer products in one or more of the areas of Figure 62 to 
support business to business exchanges. The areas include: credit ratings and 
reporting 6200, trade financing 6202, risk management 6204, settlement 6206, and 
information 6208. 

TradeDirect will allow corporate customers to gain comfort regarding the quality of 
their counterparties before engaging in online business to business trades. Figure 63 
illustrates a process 6300 for affording credit rating and reporting utilizing a 
network. In operation 6302, transactions between a plurality of buyers and sellers 
are facilitated by offering a plurality of services. Such services may include 
allowing the buyers and the sellers to negotiate terms of the transactions via a site on 
a network, exchanging forms indicating the negotiated terms utilizing the network, 
assessing a credit of the buyers by interfacing banks associated with the buyers, 
and/or initiating payment from the buyers to the sellers. During the delivery of such 
services, a history associated with the transactions is generated in operation 6304. 
The history associated with the transactions is stored in a database in operation 
6306. In operation 6308, the identity of the buyers and the sellers may be 
authenticated utilizing the network, which allows the buyers and the sellers to access 
to the history of other buyers and sellers in operation 6310. 
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In one embodiment of the present invention, the history may be supplemented with 
information on the buyers and sellers received from third parties. As an option, the 
history of the buyers and the sellers may include ratings received from other buyers 
5 and sellers. Further, the history of the buyers and the sellers may incorporate 
records of problems occurring during the delivery of the services. 

Optional credit rating and reporting services which may be offered include: 
• Bank credit rating 

10 o TradeDirect will compile credit ratings of member firms through the 



• Member posted ratings 

o TradeDirect will allow firms to post ratings of the counterparties they 



banks which are part of the TradeDirect network 



15 



have dealt with 



• TradeDirect credit history 

o TradeDirect will compile a credit history of firms which have used 
the TradeDirect system 



20 



• Third party credit rating 

o TradeDirect will draw data from third party providers of credit 
ratings 



25 



• Authentication 



o TradeDirect will authenticate participants using digital certificates 



Some of the benefits these services will provide for buyers, sellers, and for 
transacting, include: 



30 



• Buyers 



o Gain comfort regarding the products ordered 
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o Increase confidence in counterparty 

• Sellers 

o Gain comfort regarding the receipt of payment 
o Increase confidence in counterparty 

• Exchanges 

o Increase volume because barrier to usage is diminished 
o Potentially increase revenues through service charge 

Pre-approved lines of credit and online decisioning will streamline financing and 
guarantee payment. Figure 64 is a flowchart of a process 6400 for approving a line 
of credit of a buyer utilizing a network. In operation 6402, requests are received 
from a plurality of buyers for credit approval utilizing a network. In response to the 
requests, the credit of the buyers are assessed in operation 6404 by interfacing banks 
associated therewith. A predetermined amount of credit is awarded to the buyers in 
operation 6406. In operation 6408, the buyers are allowed to negotiate terms of 
transactions with a plurality of sellers utilizing the network. Thereafter, in operation 
6410, payment is initiated from the buyers to the sellers. In operation 6412, the 
sellers are provided with a guarantee on the payment up to the predetermined 
amount of credit. 

In one embodiment of the present invention, the sellers are provided with the credit 
assessment when the terms of the transactions are being negotiated by the buyer and 
the seller. As an option, during the negotiation of the terms of the transactions, 
request may be received from the buyers for an increase in credit utilizing the 
network. The credit of the buyers may be again assessed by interfacing banks 
associated therewith in response to the requests. Further, an increased 
predetermined amount of credit may be granted to the buyers. The sellers are then 
provided with a guarantee on the payment up to the increased predetermined amount 
of credit. 



# 
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In another embodiment of the present invention, forms indicating the negotiated 
terms may be exchanged utilizing the network. Further, the buyers may be 
optionally allowed to negotiate terms of the transactions with the sellers utilizing a 
site on the network. 

Optional trade finance services which may be offered include: 

• Buyer financing 

o Purchasing cards and lines of credit to provide pre-approved credit to 

accepted applicants 
o Inventory and lease financing 

• Seller financing 

o Factoring to finance short-term receivables 

o Forfeiting for non-recourse financing of longer-term receivables 

• Real-time credit decisioning 

o Real-time credit decisions will allow financing offer to be made at the 
point of need 

Some of the benefits these services will provide for buyers, sellers, and for 
transacting, include: 

• Buyers 



o 



o 



o 



Save time with pre-approved financing 

Save money with lower financing costs than letters of credit 

Potentially negotiate lower cost of goods from seller since payment is 

guaranteed 



• Sellers 



o Reduce credit risk because payment is guaranteed 
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o Easily manage cash flow as required 

• Exchanges 

o Increase volume because barrier to usage is diminished 
o Increases member entanglement 
o Potential referral revenue 

TradeDirect may provide products with which buyers and sellers can minimize the 
risk of trading. Optional risk management services which may be offered include: 

• Foreign exchange 

o TradeDirect will exchange currencies at rates better than those 
available to most members 

• Insurance 

o Insurance will be offered for shipping, warehousing, etc. 

• Hedging instruments 

o Derivatives and options will be offered on foreign exchange rates, 
commodity prices, etc. 

Some of the benefits these services will provide for buyers, sellers, and for markets, 
include: 

• Buyers 

o Save time setting up ancillary agreements on-line from one source 
o Reduce direct expenses due to purchasing power of TradeDirect 

• Sellers 

o Save time setting up ancillary agreements on-line from one source 
o Reduce direct expenses due to purchasing power of TradeDirect 

• eMarketplaces 

o Potentially increase revenues through referral income 
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o Increase member entanglement 

TradeDirect may automate most elements of payments and trade settlement. Figure 
65 is a flowchart illustrating a process 6500 for affording a settlement function 
utilizing a network. In operation 6502, a buyer and a seller are allowed to negotiate 
terms of a transaction via a site on a network. The terms include an amount of 
payment and a time frame thereof. Forms indicating the negotiated terms are then 
exchanged between the buyer and the seller in operation 6504 utilizing the network. 
By interfacing a bank associated with the buyer, a credit of the buyer is assessed in 
operation 6506. If the credit assessment is successful, payments are periodically 
executed from the buyer to the seller in operation 6508 per the terms of the 
transaction. The payments are executed automatically by accessing the bank 
associated with the buyer and authorizing payments to the seller. Upon each 
execution of a payment, the buyer is sent electronic receipts via the network in 
operation 6510. 

In one embodiment, evidence of the periodically executed payments is stored for 
later verification. Further, the seller may be sent electronic notices via the network 
upon each execution of a payment. As an option, risk associated with the 
transaction may be reduced by offering insurance. 

Optional settlement services which may be offered include: 

• ePayments 

o TradeDirect will provide a seamless global ePayment capability by 
leveraging an existing payments network; offerings include payment 
cards, ACH, SWIFT, and wire transfer 

• Straight through processing 

o Enable "straight-through processing" through integration with seller* s 
accounts receivable and buyer's accounts payable systems 
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• Electronic bill presentment 

o Bills will reliably be presented and paid in the agreed time frame 
electronically and in full 

• Electronic shipping documentation 

o Document management will be carried out digitally 

Some of the benefits these services will provide for buyers, sellers, and for 
exchanges, include: 

• Buyers 



o Receive goods more quickly due to faster turnaround time 
o Eliminate time consuming paper handling 

o Reduce transaction costs and time required to complete payment 
processing 

o Increase accuracy of document processing 



o Receive payment more quickly 

o Eliminate time consuming paper handling 

o Reduce transaction costs and time required to complete payment 
processing 

o Increase accuracy of document processing 



o Higher volume due to increased attractiveness of exchange trading 
o Potentially increase referral income 



• Sellers 



• Exchanges 



One embodiment of the present invention makes information available online to help 
buyers and sellers make informed decisions, negotiate contracts, and structure these 
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in accordance with relevant negotiations. According to this embodiment, Figure 66 
is a flowchart that illustrates a process 6600 for affording information services while 
facilitating a transaction between a buyer and a seller utilizing a network. A buyer 
and a seller are first allowed to negotiate payment terms of a transaction involving 
goods via a site on a network in operation 6602. In operation 6604, the payments 
terms and goods are compared with other payments terms and goods utilizing the 
network. Such comparison is also displayed. In operation 6606, access may also be 
had to a database of forms utilizing the network. The buyer and seller are allowed to 
complete the forms to reflect the negotiated terms utilizing the network in operation 
6608. Rules and regulations relating to the goods may also be displayed in 
operation 6610. In order to further the transaction, in operation 6612 payment is 
initiated from the buyer to the seller utilizing the network. 

In one embodiment of the present invention, information maybe displayed on 
procedures involving the goods utilizing the network. Information may also be 
displayed on current events involving the goods utilizing the network. As an option, 
risk associated with the transaction may be reduced by offering insurance. 

In another embodiment of the present invention, the buyer and the seller may be 
allowed to negotiate other terms of the transaction such as the volume of goods, 
delivery window, delivery location, and delivery mode. 

Optional information services which maybe offered include: 

• Payments and trade information 

o Regional and product-specific trade rules and regulations will be 
available on-line 

• Decision support tools 

o Tools will be available online to compare product offerings and 
payment terms 
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• Contracts 

o Purchase orders and proforma invoice templates will be available 
online 

Some of the benefits these services will provide for buyers, sellers, and for 
exchanges, include: 

• Buyers 

o Save time researching needed information 
o Enables more informed decisions 

o Provides help regarding specific procedures which must be followed 

• Sellers 

o Compare offers more quickly and accurately 

• Exchanges 

o Increase volume because barrier to usage is diminished 
o Potentially increase revenues through referral income 

Figure 67 is a flowchart depicting a process 6700 for contracting and fulfilling a 
business to business trade utilizing a network according to one embodiment of the 
present invention. In operation 6702, a buyer and a seller are allowed to negotiate 
terms of a transaction via a site on a network until an agreement is reached. In 
operation 6704, the buyer and the seller are prompted to confirm a form reflecting 
the negotiation terms of the transaction that have been agreed upon. Such confirmed 
form is stored in a database. Documents which support the transaction are received 
in operation 6706 utilizing the network. Such documents are stored in the database 
in operation 6708. The form and the documents in the database may be checked in 
operation 6710 based on a predetermined set of rules using a rule-based engine. 
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Further, in operation 6712, funds may be released to the seller upon the form and the 
documents being successfully checked. 

In one embodiment of the present invention, the form is a combined purchase order 
proforma invoice. As an option, a freight shipper and/or an insurer may be 
contracted to become involved in the transaction. 

In another embodiment of the present invention, authorization may be received from 
the buyer before the funds are released. Further, a consolidated statement may be 
sent to the buyer. 

Figure 68 illustrates a process for allowing buyers 6800 and sellers 6802 to gather 
information about each other. Reference numerals 1-4 set forth the order of the 
operations of the process. 

Figure 69 is a flowchart that depicts a process 6900 for a credit application process. 
In operation 6902, a credit application is received from a buyer utilizing a network. 
In response to the receipt of the credit application, the credit application is sent to a 
bank via the network in operation 6904. This is for assessing the credit of the buyer 
based on the credit application. If the credit is approved, the buyer is registered in 
operation 6906 by assigning an identifier thereto. Next, in operation 6908, a 
password is generated for the buyer. The identifier and the password are then 
stored in a database in operation 6910. Thereafter, in operation 6912, the buyer is 
sent the password utilizing the network. In operation, the buyer may use the 
password and identifier to initiate transactions on the network. In operation 6914, 
the buyer is issued a card reflecting the identifier. 

In one embodiment, the card is delivered to the buyer by courier. A notice is then 
sent to the bank upon receipt of the card by the buyer. As an option, the credit 
application may include financial statements of the buyer. Further, the step of 
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assessing the credit of the buyer may include approving a credit limit, and setting up 
a line of credit. 

Figure 70 illustrates a process for screening a buyer 7000 before credit is given to 
the buyer by a credit provider 7002. The operations which carry out the process are 
enumerated in order by numerals 1-6. 

Figure 71 depicts a process for allowing a company to guard against risk before 
entering into a trade by allowing purchase of a risk management product. The 
operations which carry out the process are enumerated in order by numerals 1-5. 

Figure 72 is a flowchart illustrates a process 7200 for initiation of an agreement 
utilizing a network. In operation 7202, a buyer and a seller are allowed to negotiate 
terms of trade utilizing a network. A form is received from the buyer in operation 
7204 indicating the terms of trade utilizing the network. Also received utilizing the 
network in operation 7206 is an identifier of the buyer. Thereafter, the form is sent 
to a bank in operation 7208 for assessing the credit of the buyer utilizing the 
network. The bank to which the credit application is sent is based on the identifier. 
Next, in operation 7210, the form is forwarded to a seller along with the assessment 
of the credit of the buyer. In operation 7212, the seller is permitted to digitally sign 
the form utilizing the network. The digitally signed form is received from the seller 
in operation 7214 utilizing the network, after which a notice is sent to the buyer in 
operation 7216 indicating that the digitally signed form has been received from the 
seller, thus initiating the agreement. 

In one embodiment of the present invention, an identity of the buyer is 
authenticated prior to sending the form to the bank. Such identity may be 
authenticated by requiring the submission of an identifier and a password. 
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In another embodiment of the present invention, the credit of the seller may be 
verified. As an option, the form may include a combined purchase order pro forma 
invoice. 

Figure 73 illustrates a process for initiating a transaction which includes an 
ePayment. The operations which carry out the process are enumerated in order by 
reference numerals 1-6. 

Figure 74 illustrates a process 7400 for order fulfillment utilizing a network. In 
operation 7402, a buyer and a seller are permitted to negotiate terms of a transaction 
utilizing a network. In operation 7404, a form is received from the seller or the 
buyer utilizing the network. Such form is created based on the transaction terms and 
identifies a forwarding agent that receives a product associated with the transaction 
from the seller for the purpose of delivering the same to the buyer. Payment is then 
initiated to the seller for the product in operation 7406. This is accomplished by 
interfacing a bank utilizing the network. A notice is sent to the forwarding agent in 
operation 7408 upon the finalization of the payment for the purpose of releasing the 
product to the buyer. 

In one embodiment, a plurality of documents which support the transaction are 
received from the buyer. As an option, at least a portion of the documents may be 
forwarded to the bank for payment authorization purposes. Further, it may be 
confirmed that the documents are received within a predetermined time period. Still 
yet, the documents may be forwarded to the bank for facilitating the finalization of 
the payment. Optionally, the documents may be scanned and forwarded to the bank 
utilizing the network. 

Figure 75 illustrates a process for a transaction in which a buyer 7500 sends an 
ePayment sent through TradeDirect. The operations which carry out the process are 
enumerated in order by reference numerals 1-6. 
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Figure 76 is a flowchart of a process 7600 for performing a direct fund transfer 
utilizing a network. In operation 7602, a buyer and a seller are allowed to negotiate 
payment terms of a transaction utilizing a site on a network after which the seller 
ships goods associated with the transaction to the buyer. In operation 7604, an 
identity of the buyer is authenticated utilizing the network after which, in operation 
7606, an indication is received from the buyer to pay the seller for the goods on the 
network. Thereafter, in operation 7608, a database is queried in order to retrieve 
payment information related to the buyer. The present invention then interfaces a 
bank in operation 7610 utilizing the network for effecting payment to the seller 
based on the payment information and the payment terms. 

In one embodiment, the payment information may include an identifier for the bank 
and an associated account identifier. As an option, the direct fund transfer may be 
carried out by a party separate from the bank, the buyer, and the seller. 

In another embodiment, the buyer and the seller are allowed to negotiate payment 
terms of a transaction using a chatroom. Further, the identity of the buyer may be 
authenticated using a password. 

Figure 77 illustrates a process for open accounts information in accordance with an 
embodiment of the present invention. Reference numerals 1-6 set forth the order of 
the operations of the process. 

Figure 78 is a flowchart illustrating a process 7800 for account settlement utilizing a 
network. In operation 7802, a buyer is allowed to select from a group of options in 
order to settle an account utilizing a network. The options include settling a 
minimum balance, partially settling, settling a full balance, and applying for an 
import loan on payment due date. The selected option is then received in operation 
7804 utilizing the network. In operation 7806, finance interest may be booked 
against the buyer for an unpaid portion of the account if the selected option includes 
either settling a minimum balance or partially settling. If the selected option 
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includes settling a full balance, the account may be reconciled in operation 7808. 
On the other hand, if the selected option includes applying for an import loan on 
payment due date, an import loan may be booked and a credit line may be 
transferred to a trade loan line. 

In one embodiment of the present invention, ownership of goods may be released to 
the buyer by transferring title thereto if the selected option includes either settling a 
minimum balance or partially settling. As an option, a consolidated card statement 
may be sent to the buyer utilizing the network. 

In another embodiment of the present invention, a third party who reconciles the 
account may be engaged if the selected option includes settling a full balance. 

Figure 79 illustrates a process for financing or settling an account according to one 
embodiment of the present invention. Reference numerals 1-5 set forth the order of 
the operations of the process. 

Figure 80 illustrates a process for procuring information during the course of a 
transaction in accordance with an embodiment of the present invention. Reference 
numerals 1-4 set forth the order of the operations of the process. 

DEVELOPMENT FRAMEWORK (IDEA) 

Figure 81 is an illustration of the Integrated Development Environment Architecture 
(IDEA) that may be used to create a system for implementing the foregoing 
embodiments. The Integrated Development Environment Architecture provides a 
development environment framework and associated guidelines that reduce the 
effort and costs involved with designing, implementing, and maintaining an 
integrated development environment. IDEA takes a holistic approach to the 
development environment by addressing all three Business Integration components: 
organization, processes, and tools. 
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The development environment is a production environment for one or several 
systems development projects as well as for maintenance efforts. It requires the 
same attention as a similarly sized end-user execution environment. 

The purpose of the development environment is to support the tasks involved in the 
analysis, design, construction, and maintenance of business systems, as well as the 
associated management processes. The environment should adequately support all 
the development tasks, not just the code/compile/test/debug cycle. Given this, a 
comprehensive framework for understanding the requirements of the development 
environment can be used. 

Another reason for the comprehensive framework is that it is important to get the 
development environment right the first time. Changing the development 
environment when construction is fully staffed entails serious disruptions and 
expensive loss of productivity. 

Experience has shown that within the same medium- to large-size project, with the 
same people, moving from a poor to a good development environment, productivity 
is improved by a factor often for many tasks. The improvements come in two 
categories: 

• The elimination of redundant and non value-added tasks 

• The streamlining of useful tasks 

While it seems intuitive that most tasks can be streamlined, the following list gives a 
few examples of redundant tasks that must be eliminated: 

• Analysis to determine how to merge the uncoordinated changes applied by two 
programmers to the same module 
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• Re-entry of the source code and retesting of a module, which was accidentally 
deleted 

• Recurring discussions about "what a design packet should contain" or "what 
constitutes good programming style in a particular context" 

• Repeated design, coding, testing, and maintenance of very similar logic (for 
example, error handling, date conversion and manipulation, main structure of a 
module) 

• Searching for the manuals of a particular productivity tool to find information 

• Remigration to system test of a cycle, because the impact analysis for a change 
request was incomplete 

• Requesting support from another team (for example, environment support, 
information management) and waiting unnecessarily for a response 

On a smaller project, these problems can be solved using a brute force approach. 
This becomes very expensive as the project grows, and finally impossible . A well- 
designed development environment becomes important as the project team reaches 
20-30 people and is absolutely critical with a project size of more than 50 people. 

The investment required to design, set up, and tune a comprehensive, good 
development and maintenance environment is typically several hundred 
development days. Numbers between 400 and 800 days are commonly seen, 
depending on the platforms, target environment complexity, amount of reuse, and 
size of the system being developed and maintained. 
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DEVELOPMENT ORGANIZATION FRAMEWORK 

Figure 82 is an illustration showing a Development Organization Framework in 
accordance with one embodiment of the present invention. When designing a 
business application, it is crucial to keep in mind the organization that will use the 
system. The same is true of the development environment. The development 
organization's size, structure, experience, and maturity should strongly influence the 
choice of tools and the way the tools are integrated. If this link is not understood, 
the benefit of tool support will be minimal in many areas, and may significantly 
reduce productivity. 

In the same way, when a new business capability is introduced, it is crucial to keep 
in mind the needs for training and organizational change that which may accompany 
the technical change. This is also true of the development environment. When a 
new development environment is put in place, the developers need to learn not only 
how each individual tool works (for example, how to use the compiler), but also 
how the tools work together to support the organization as it performs well defined 
processes. 



The Business Integration Methodology (BIM) provides valuable information on 
organizational issues. 

Relying on the Business Integration Methodology and its project organization 
guidelines (0940 - Organize Project Resource Task Package), the following should 
be prepared: 



• A list of responsibilities covering both responsibilities for end products and 
those for on-going processes 
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• A Responsibility, Accountability, and Authority profiles deliverable (RAA) for 
each role in the Development team, making sure that all the responsibilities 
listed earlier are covered 

The RAA profiles deliverable consists of statements about the responsibilities, 
accountability, and authority of each of the positions in the development 
organization. These statements define the role of each position in terms of: 

• Responsibility — What objectives the position is expected to accomplish 

• Accountability — How and by whom the performance will be measured 

• Authority — The position's decision-making capabilities and limits 

In accordance with the IDEA Model, the following management teams with 
responsibilities for the key management functions are defined as: 

• The Information Management team 8202 

• The Quality team 8204 

• The Environment Management team 8206 

• The Release Management team 8208 

• The Configuration Management team 8210 



• The Problem Management team 8212 
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• The Program and Project Management teams 8214 

• The Security Management team 8216 

Together, these teams support the efforts of the System Building team, which is 
charged with the analysis, design, build, and test of the system to be developed. 
These teams represent real roles, and on a given program the same people may play 
different roles. 



Security Management 

The evolution of new technologies and expanded access to a virtual world has 
increased the security risk of conducting business. It is therefore essential to 
recognize the need for a new unit in the organization, specifically dedicated to 
ensuring that security is handled appropriately. At the Program level, the Security 
Management unit needs to: 

• Ensure all security issues are effectively addressed throughout the program (all 
business and IT processes). 

• Act as facilitator and approving body for all new and existing initiatives that 
contain security components. 

• Own responsibility for the organization and facilitation of working groups that 
would address security issues. 



• Be responsible for development and maintenance of the Security Plan. 
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Figure 83 is an illustration showing a security organization according to one 
embodiment of the present invention. A Security Management Team may have a 
security management 8300, under which are an administration team 8302, a projects 
& planning team 8304, and a business process security team 8306. The size of the 
Security Management team, and the way in which it is integrated into the 
development organization depends on the degree to which security is a factor for 
each specific environment. For example, the security risks associated with an 
Internet-based online banking system are far greater than those of a fully isolated 
client/server system, and therefore warrant a larger team with broader 
responsibilities and greater influence. 



More details about the Security Management team, and other security aspects can be 
found in the Security in eComerce Executive Planning and Implementation Guides 
to be published by Global TIS Security. 

Information Management 

The Information Management team is responsible for ensuring that the project's 
knowledge capital and information resources are managed effectively. This 
includes: 

• Ensuring integrity 

• Ensuring accessibility 

• Ensuring quality and consistency 
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Information Management encompasses Repository management, but generally has a 
broader scope than merely the repository contents, because most repositories are not 
capable of holding all the information resources of a project. It is, for example, 
common to have key project information reside in a combination of repositories, 
teamware databases, flat files, and paper documents. It is the Information 
Management team's responsibility to ensure consistency across all these formats. 

The responsibilities of the Information Management team therefore cover: 

• Repository Management 

• Folder Management 

• Object Management 

• Media Content Management 

• Information and data reuse coordination 

In addition to managing the information for the System Building team, the 
Information Management team must also manage the information resources of the 
other management processes - quality management, environment management, and 
project management. 

In order to delineate the responsibilities of the Information Management team, it is 
useful to state those areas that are out of scope. The following are not included: 

• Performance of daily backups - this is handled by the Environment Management 
team 
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• Database administration - this is part of the Architecture team responsibilities 

• Performance tuning of the information repositories - this is handled by 
Environment Management 

Repository Management 

The Information Management team is ultimately responsible for the contents of the 
repository. They need to have an intimate understanding of the repository structure 
and the rules that govern how different objects should be stored in the repository. 
Although most of the input to the repository are entered by designers, the Repository 
Management team must manage this population process. Rather than taking a 
policing role on the project, they should work as facilitators - helping the designers 
do things correctly the first time, thereby maintaining the integrity of the repository. 
Without strong repository management, the benefits of using a repository quickly 
diminish. 

In many situations the Information Management team must make decisions that 
affect functional areas. To empower the Information Management team, the 
Application teams should include the Information Management team in relevant 
design discussions. This facilitates the validation of design outputs. 

Folder Management 

Folders (or directories) can be very useful in gaining control over the overwhelming 
amount of information produced on a large project. Their utility greatly increases if 
they are managed appropriately. This management is based on easy-to-follow, easy- 
to-enforce standards. 
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Object Management 

The responsibilities involved with object management are very similar to those 
involved with repository management. However, in order to facilitate and promote 
reuse, it is recommended to have a librarian whose responsibilities include: 

• Reviewing designs 

• Packaging classes and components for reuse 

• Managing maintenance and upgrades of common components (a strong 
relationship with Configuration Management team is required) 

Media Content Management 

The methods of handling media content are somewhat different from those 
surrounding more traditional development content such as code or documentation, 
for this reason, a role should be defined that is responsible for the management of all 
media content. 

Quality Management 

The Quality team is responsible for defining and implementing the Quality 
Management Approach, which means defining what Quality means for the Program 
Leadership, and then implementing the procedures, standards, and tools required to 
ensure the delivery of a quality program. The Quality Management Approach 
addresses concepts such as expectation management, quality verification, process 
management, metrics, and continuous improvement. 
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Since quality is the result of the interaction of many teams working on multiple 
processes, the Quality team is responsible for ensuring effective cooperation 
between teams and good integration of the development processes. The Quality 
team must therefore forge strong links with all the other project teams. 

It is important to note that the Quality team is not only responsible for ensuring the 
quality of the system building process. The Quality team is also directly involved in 
ensuring the quality of the other IDEA management processes. 

Program & Project Management 

The Program Management team is responsible for delivering business capability. In 
this respect, it is responsible for the System Building and other management teams. 
In addition, other management responsibilities that do not have a specific team or 
role defined within IDEA also belong to the Program Management team. These 
include: 

• Contingency Management 

• Financial Management 

• Issue Management (decisions to be made regarding the development of the 
business capability, 

• not to be confused with problem management) 

• Program Performance Reporting 



• Resource Management 



• Risk Management 



• Vendor Management 

The Project Management team is responsible for producing a deliverable or set of 
deliverables. As such, it is responsible for: 

• Planning and control of delivery 

• Milestones and schedule 

• Resource consumption 

• Risk and quality (at deliverable level) 
Configuration Management 

The Configuration Management team is responsible for defining the approach the 
program takes to deal with scope, change control, version control, and migration 
control, and for putting in place the policies, processes, and procedures required to 
implement this approach. 

In other words, the team is responsible for maintaining the integrity of software and 
critical documents as they evolve through the delivery life cycle from analysis 
through deployment. 
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Release Management 

Delivering a system on a release-based approach means delivering the system in a 
series of consecutive releases, increasing or refining functionality progressively. 
Some of the main drivers to such an approach include: 

• To release business benefits early 

• To mitigate impact on the organization 

• To keep the change program up to date 

• To optimize processes 

• To test proof of concept 

• To reduce risk 

The Release Management team is responsible for: 

• Planning the capability release design and development effort, based on the 
capability development approach and timeline. 

• Measuring and monitoring progress using established processes to ensure that a 
capability release is delivered on time, within budget, and that it meets or 
exceeds expectations. 

• Managing project interdependencies to ensure delivery of the capability release. 
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• Ensuring that resources are used effectively across projects for the release. 

As with many other management responsibilities described in IDEA, Release 
Management is more a role than a function. It is good practice to have as many 
areas as possible represented in the Release Management team; for example, Design, 
Construction, Configuration, and Environment Management team members would 
make up a typical Release Management team, each providing input based on their 
own perspective. ■ ■ • - 

Environment Management 

Just as a business application requires support and system users require service, the 
development environment requires system operations daily, and developers require 
ongoing support in order to use the environment effectively (In fact, the complexity 
and frequency of these operations is often greater than that of the execution 
environment). 

To ensure that this area receives the necessary attention, an Environment 
Management team 8400 should be assigned these tasks. Figure 84 is an illustration 
showing the Environmental Management Team responsibilities. 

The Service Group 8402 serves as a single point of contact for developers. It 
interfaces with the Architecture team to provide answers to questions from 
developers. To avoid adding overhead to the issue resolution process, the support 
group must be staffed adequately to ensure that all questions are answered. For 
example, the support group should recruit people from the Technology Infrastructure 
team at the completion of Technology Infrastructure development. 
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Problem Management 

Problem Management is concerned with the discrepancies that result from the 
testing process and the management of design problems detected during verification 
or validation steps throughout the development process. 

5 The Problem Management team is responsible for defining the problem tracking and 
solution process, and for providing tools and procedures to support the solution 
process. 

System Building 

The Business Integration Methodology (BIM) describes System Building under the 
10 following activities: 

• Design application 

• Build and test application 

• Design technology infrastructure 

• Build and test technology infrastructure 

15 For this reason, the System Building teams are organized into application and 
technology Infrastructure. 
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Application Team 

The Application team 8500 consists of three separate subteams: Application 
Architecture 8502, Application Development 8504, and System Test 8506. Figure 
85 is an illustration showing the Application Team structure and responsibilities. 

The structure of the Application team evolves as the development process continues 
- as the development of the application architecture components is completed, the 
Application Architecture team's roles may change. While the team continues 
maintaining the application architecture components, some team members may be 
deployed to the Application Development team. Here their roles can include helping 
application developers to correctly use the architecture components, providing 
development support, and performing code reviews, and so forth. 

As systems become more user-facing, important new roles are emerging that must 
be integrated into the Application Development teams: 

a) Media Content Design 

For any system with a user-facing component, it is extremely important that media 
and design specialists are involved as team members at an early stage in the design 
of the system. In systems with simple user interfaces, this helps to ensure usability 
and consistency. As user interfaces become more complex, the early involvement of 
design experts not only leads to more creative and attractive user interfaces, but also 
reduces the risk of further alteration to work at a later stage. 
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b) Usability 

Often coupled with Media Content Design, it is vital that a role for usability is 
defined within the Application Development teams. This will ensure the usability of 
the system from the perspective of target user groups. 

Technology Infrastructure Team 

The technology infrastructure evolves throughout the project and responsibility for 
managing and evolving the infrastructure must be clearly defined. Therefore, rather 
than having a single amorphous 'technical team 1 (responsible for operations, support, 
architecture evolution, and more), it is important to define a dedicated technology 
infrastructure team. By allowing the technology infrastructure team to focus on the 
technology infrastructure, rather than the day to day running of the environment, the 
project increases the chances that the technology infrastructure will provide good 
support for the business applications. 

In practice, the Technology Infrastructure team is the team that will implement the 
IDEA framework. 

The Technology Infrastructure team is responsible for: 

• Data design and management 

• Database administration 

• Database tuning 

• Execution architecture design and construction 
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• Development architecture design and construction 

• Operations architecture design and construction 

• Network design 

• Technical standards design and documentation 

• System software selection 

• Performance tuning of the final system 

• Security infrastructure development 

Note: The responsibilities of the Technology Infrastructure team may overlap with 
those of the Application Architecture team, and on some projects the two teams are 
often combined. 



DEVELOPMENT PROCESSES FRAMEWORK 

A thorough understanding of the development processes is a prerequisite for 
ensuring that the tools effectively support the organization and the processes they 
are intended to support. 
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The Development Process Model 

The Development Process Model is a framework that facilitates the analysis of the 
many concurrent processes of systems development. This analysis helps understand 
process interaction, which, in turn, affects organizational interaction and defines a 
5 need for tools integration. 

The Process model is simple - at its core is the system building process, which is 
surrounded by eight key management processes. 

€3 . . 

u3 The core activity - systems building, depends strongly on support from the 




10 



surrounding management processes, which all affect each other: 



a) Information Management manages the information that supports the entire 
project - information that is used both in systems building and in other 



management processes 



b) Security Management covers all areas of development security, from 
coding standards, to security verification. 
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c) Quality Management pertains to all areas of the development environment 



d) Program and Project Management must manage all the management 
processes in addition to managing the systems building process 



e) Environment Management supports the environment where management 
processes are performed, and where systems are being built 
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f) 



Release Management manages the simultaneous development of multiple 
releases 
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g) Configuration Management, often closely linked with release management 
covers the version control, migration control and change control of system 
components such as code and its associated documentation 

h) Problem Management pertains to the problem tracking and solution process 



Process Definition 

For a given project, each of the processes must be defined at a greater level of detail 
than that which any methodology can achieve. This additional specification consists 
of a set of procedures and standards that specify how to perform the work and what 
to produce at each step. 

Standards specify what the results should look like. They may include industry 
standards and more formal (de jure) standards, such as POSDC compliance, but most 
standards are project specific and determine, for example, how to structure and name 
system components and where to place system components. Standards make it 
possible for a large team to exchange information effectively and to work 
productively together. 

Standards should focus on what must be common, and should not become a goal in 
themselves. Erring on the side of over-standardization stifles productivity. It is, 
however, often the case that unforeseen events (such as platform demise, tool 
evolution) will be easier to tackle the more unified the development approach has 
been. Unfortunately, there is no substitute for experience when making the detailed 
decisions on exactly what should be standardized. Factors to take into account must 
at least include: 




-90- 



• Life expectancy of the system under development - the higher the life 
expectancy, the more standards are warranted 

• Life expectancy of the development organization - the higher the life 
expectancy, the more standards are justified 

• Attrition - a stable organization can tackle more detailed standards than a volatile 
one 

• Expected change in the environment - a high rate of change provides greater 
opportunity to reap the benefits of a standardized approach 

Procedures specify how to perform a task. They are generally guided by the 
methodology but provide information at a lower level of detail. They are highly 
environment-specific, and take into account the organization, the standards, and the 
tools in the environment. Procedures often specify the techniques to be used. They 
may specify which tools to use and how to use the tools that support these 
techniques. 

Many processes require individual judgment, and the way to perform these 
processes cannot be specified in detail. In such cases, it may be valuable to provide 
guidelines that do not have the mandatory flavor of procedures but rather that of 
valuable advice. 

While it is easy to generate zeal to set up standards and procedures at the beginning 
of a project, it can sometimes be more difficult to ensure that these are enforced 
throughout the project. Two considerations are useful. Firstly, standards must be 
easy to follow. It should be easier to follow the standard than doing things any other 
way. This is generally achieved by supplying the training, tools, and support needed 
to facilitate a given work style. For example, developing and distributing 
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application program shells, which respect the architecture and standards, facilitates 
programming and contributes to ensuring broad standards compliance. Secondly, 
the responsibility for enforcing standards must be clearly identified and assigned. 
Standards enforcement must take place as a natural part of the process and at well- 
defined check points before work flows to the next task, or (even more importantly) 
to the next group or team. 

A very useful way of complementing the specification of procedures is to provide 
samples. Samples can sometimes convey a message much faster than pages of 
explanatory prose. Sample programs are generally very useful. Other samples may 
include logs, which demonstrate interaction with tools, a sample change request, or a 
sample request for technical support. Samples can sometimes be created efficiently 
by taking screen dumps. This can be much faster than specifying what the screen 
should look like in theory. 

Samples and standards must be high quality - any quality breach will be multiplied 
when developers start using them. It is therefore imperative that samples and 
standards not be created in a vacuum but be based on concrete experience with the 
project's development environment. Some pilot development work often proves 
extremely useful when fine tuning the standards. 

When documenting the process, it is useful to develop an approach and process 
description for each project segment and for each high-level process. This document 
summarizes the support available for that segment or process. It refers to all the 
standards, procedures, guidelines, and examples relevant to a collection of tasks. 
Such a summary document makes it easier for developers to navigate the standards 
and hence to follow them. 
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Process Integration 

To ensure that the project team works effectively together, numerous processes must 
be integrated. A simple example is provided by the required integration between 
design and construction. A more subtle one is the integration of product quality 
inspection and the continuous improvement process. 

As process integration frequently involves several teams, it is crucial to understand 
the interfaces between processes and teams to ensure good hand-offs. This 
understanding must have a direct impact on tools integration, so that integrated 
processes are supported by integrated tools. Tools that support multiple processes 
performed by the same individual must, at a minimum, be integrated at the user 
interface level and should ideally be integrated at the process level. Tools that 
support processes performed by different individuals may only have to be integrated 
at the data level. 

Security Management 

Processes must be put into place in order to ensure security is properly designed and 
built into the system that is being developed, including: 

• Definition of security requirements based on business risk 

• Development of security standards, guidelines and procedures 

• Implementation of security controls 

• Security validation 
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Security Requirement Definition 

Security requirements are the outcome of the security Risk Assessment. This is the 
process of identifying business risks, identifying system vulnerabilities or 
weaknesses that can impact those risks, and recommending mechanisms to control 
5 the vulnerabilities. Specific confidentiality, integrity and availability requirements 
for the new system and the development environment are defined through this 
process. 

Security Standards, Guidelines and Procedures 

Security standards, guidelines and procedures provide security direction to the 
implementation. They will help define how the security requirements developed 
through the Risk Assessment must be addressed in all areas of the development 
environment. They will include security standards for the development environment 
infrastructure, procedures for the development processes, standards for the design of 
the security architecture and security guidelines for programming. It is especially 
important to ensure the security of the development environment because if these 
systems are broken into and back doors are introduced, it may lead to later 
compromise of the production system. It will be the responsibility of all developers 
that these security controls are implemented and adhered to throughout the 
development process. 

20 Security Validation 

In order to ensure the security of the system, periodical security audits should be 
arranged, in order to verify that the processes and architecture and application 
components that are being developed conform to security proven practices. This 
may be done by an external body specializing in security (such as Global TIS - 
25 Security) in the form of interviews, architecture and code reviews, and automated 
tool assessment. 
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Information Management (202) 



A vast amount of information is generated within the development environment, 
which needs to be carefully managed (for example, design documentation, 
application code, media content, test plans and test data). Information Management 
generally involves Repository Management, Folder Management and, where 
applicable, Object Management and Media Content Management. 

Since a number of teams rely on the service provided by the information 
management team, it is important that the level of service to be provided be chosen 
carefully, documented, and communicated. The arrangement should take the form 
of a Service Level Agreement (SLA). Such an SLA typically defines how quickly a 
new data element is created and how repository changes are communicated. More 
generally it defines the division of responsibilities between the information 
management team and the other project teams at a detailed level. 

Repository Management (8102) 

Repository Management includes activities such as: 

• Monitoring and controlling update activities in the repository 

• Receiving and validating data element change requests 

• Creating and modifying data elements 
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• Enforcing project standards regarding repository objects 

• Validating the contents of the repository to avoid redundancy and 
inconsistencies 

• Ensuring accuracy of the repository contents so that the repository reflects the 
applications being developed 

• Importing and exporting from one repository to another 

• Maintenance of the information model (or metamodel), which describes how 
data is represented within the repository 

As many repositories do not provide sufficient versioning functionality, it is 
common to have more than one repository on large projects. Typically, there may 
be one repository for development, one for system test, and one for production. This 
allows better control, but also requires significant resources to move repository 
objects from the development environment to the system test environment. By 
merging the development and system test repositories, the medium-sized project has 
a potential for productivity gains. If these gains are to be realized, great care must 
be taken when making corrections during system test. As a common repository is 
shared, any error analysis involving repository objects must take into account the 
possibility that these objects could have changed since the previous migration to 
system test. This situation can be managed by meticulously maintaining a 
comprehensive change log. 

Another reason for maintaining several copies of the repository is the existence of 
concurrent projects focusing on different releases. If this is the case, it may be 
beneficial to maintain delta repositories, which document those components that 
have been modified. This requires strict repository management but the reward can 
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be significant. It allows the merging of several releases, which have implemented 
complementary functionality, but which have modified a few shared components. 

A single development environment may have to deal with multiple repositories: 

• For functional reasons, one repository might be integrated with an upper-case 
design tool and the other with a lower-case generation tool 

• In a multisite environment, repositories may be distributed over different 
locations. In order to keep these repositories synchronized, well defined 
development processes must be implemented. 

Repository Management can be divided into the following areas: 

• Security 

• Maintenance 

• Validation and mass change 

• Analysis, reporting, and querying 
Security 

Restricted access to various repository object types is necessary to ensure high 
quality repository content, because developers sometimes take shortcuts and make 
unauthorized changes to meet their deadlines. When standards have been set, a good 
way to enforce them is to restrict personnel through the use of locking mechanisms. 
Access to repository object types will change throughout the project. 
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The data elements should usually be controlled by the Repository Management 
team, because they are the basic building blocks of the system and have broad reuse. 
Poorly defined data elements can cause inconsistency, redundancy, and generation 
errors. Data elements should therefore be locked at least by the time construction 
starts, and possibly earlier, depending on the discipline of the team. Project 
members must be allowed to browse the data elements, but only the Repository 
Management team should be allowed to modify or unlock data elements. In some 
repositories, it is difficult to restrict the creation of repository objects. If this is the 
case, it may be acceptable to let designers create data elements if these are reviewed 
and locked at the end of each day. Increased control can be obtained by having 
designers submit requests for new data elements to the repository administrator. 
This allows the repository manager to evaluate whether the new data element is 
justified, or whether an existing one should be used. 

Repository Maintenance 

a) Creating and maintaining data elements 

Requests for data element changes can be forwarded using a database or paper-based 
system. Based on functional and technical knowledge, the repository administrator 
evaluates the requests and may involve other teams to make appropriate decisions. 

The database used to request data element changes during design and programming 
should be separate from the project's change request database. This will simplify 
and speed up the change process. When data elements have to be changed during 
system test, however, the impact can be much greater, and the regular change 
request database should be used. 

Whenever a data element is changed, impact analysis must be performed to 
understand the side-effects. Where-used reports are useful to determine these side- 
effects. The repository manager must be able to obtain the list of direct references 
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and the list of all components affected indirectly (transitive closure). In the latter 
case, a message based on a record containing a group, which makes reference to a 
changed data element is considered to be indirectly affected by the change. 

When adding a data element, no functional equivalent must exist, because 
redundancy creates difficulties for impact analysis and future maintenance. 

b) Creating and maintaining other repository objects 

The objects related to dialog definitions, reports, messages, and so forth, are usually 
maintained by the designers and programmers. When the dialogs and report 
programs are tested, approved, and ready to be promoted to the system test 
environment, the related objects must be locked. This is the responsibility of the 
Repository Management team. 

Repository Validation and Mass Changes 

Keeping thousands of data elements consistent and in compliance with project 
standards requires a sustained effort. This daily effort is crucial to avoid a massive 
clean-up, which would be necessary if the repository manager ever lost control of 
the repository. 

Detailed, project-specific standards should exist for defining repository objects. 
These standards can form the basis for a repository validation program, which can 
run through the entire repository and report on detected deviations from standards. 
In some cases, this program can also enforce the standard. 

Mass changes to the repository can be performed when the validation reports show 
the occurrence of many standards violations that follow a common pattern. This 
may occur in cases where: 
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• Project standards have been incomplete 

• Project standards have changed 

• Repository management has been poor 

• New objects have been imported from another repository 
Analysis, Reports, and Queries 

Certain reports should be run daily, such as the list of new data elements or modified 
data elements. These reports can serve as an audit trail of changes and can be used 
to communicate changes to the entire team. Procedures should specify which 
reports are run daily and what their distribution should be. 

The Repository Management team performs certain analyses repeatedly. Standard 
analyses such as impact analyses should be specified in detail to facilitate staffing 
flexibility. 

When supporting specific kinds of repository analysis, the Repository Management 
team can provide custom reports or ad hoc queries that satisfy particular needs. 

Folder Management (8104) 

It is important to set up and communicate a detailed folder structure with specified 
access rights from the beginning. Contents of folders must be checked regularly to 
ensure that folders contain what they are supposed to. 



Two main strategies exist. 
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-100- 

• Folders can be organized by type of component so that one folder contains all 
the include files, one folder contains the source modules, one folder contains 
executables, and so on. 

• Folders can also be organized functionally so that all the common components 
reside in one folder and each application area stores its components in its own 
folder. 

Choosing the strategy depends on how components are named, on the number of 
components, and on the tools used. If naming standards make it easy to identify the 
component type (for example, by using suffixes), organizing them by functional area 
is generally useful and straightforward to administer. Some tools assume that 
closely linked files (for example, source and object modules) reside in the same 
folder. 

Another important distinction is the one between work in progress and completed 
documents that have been approved. This distinction can be supported by a folder 
structure with carefully chosen access rights. 

This distinction makes it easy to retrieve a consistent copy of project documentation 
for someone who is new to the project. 

While scratch folders may be useful in certain contexts, the proliferation of 
miscellaneous folders with cryptic names can make it very difficult to navigate the 
information. Some useful guidelines include: 

• Keep the folder structure under central control. 



• Within personal folders, allow users to create any folder structure. 
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• Clearly assign ownership for the contents of each folder. 

• Document each folder, either in a central location, or in the form of a readme 
type file within the folder itself. The high-level documentation should include 
the purpose of the folder and the kinds of contents it should hold. 

• Perform regular clean-up, by backing up redundant or misplaced files and then 
removing them. 

Media Content Management (8 1 06) 

The unique nature of media content means that it cannot be treated in the same way 
as 'standard 1 formats, such as source code or design documentation. The major 
differentiating factors are its sheer volume (media files can range from a Kilobyte to 
multiple Gigabytes), and the complexity of its associated formats (i.e. it is not easy 
to f look into' a media file and understand its contents). For this reason, some of the 
processes that support multimedia content management must be handled differently. 

The three major processes that are required to support media content management 
are: 

• Storage management 

• Metadata management 



• Version control 
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Storage Management 

Storage management concerns the methods of storing and retrieving media content. 
The cost of data storage may be decreasing, but it is still the case that for large 
volumes of media it is often uneconomical to store everything on-line. For this 
reason, processes must be implemented to manage where data should be stored, and 
how it may be transitioned from one location to another. There are three ways to 
store data: 

• On-line (Instant access, for example, hard disk) 

• Near-line (delayed access, for example, CD-ROM jukebox) 

• Off-line (manual access, for example, CDs or tapes on shelves) 

When deciding on where media content should be stored, there is always a trade-off 
between accessibility and cost (on-line storage being the most accessible and most 
expensive, and off-line the cheapest but least accessible). The decision of which 
method to use for which data may depend on a combination of its type, volume, 
version (i.e. latest or historic) and accessibility requirements. 

Metadata Management 

Data about the media that is being stored is an important commodity that must be 
managed. As the volume of media content grows, it is vital to be able to understand 
characteristics of the media, in order to be able to manage it correctly. Examples of 
metadata include: 



• Media type (for example, MPEG video, JPEG image) 
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• Media settings (for example, sample rate, resolution, compression attributes) 

• Usage details (which module uses the content) 

• Media source (for example, Source, author, creation date) 

• Legal information (for example, whether the media is copyrighted) 
Version Control 

As with standard development code, when media content is created and edited, a 
revision history of changes should be retained. This way, if it is necessary to revert 
to an original piece of media content, it is not necessary to go all the way back to the 
original source (which in the case of finding an image in a CD-ROM library 
containing 10,000 images, for example, could be a difficult task). In practice, this 
may mean storing the original and final copies of media (especially where volume is 
an issue). For this reason, a process for managing multiple versions of media 
content must be put into place. _ 

The more advanced media content management tools may provide much of the 
functionality required to support these processes, but where this is not the case, the 
processes must be implemented manually. 

c) Legal Issue Management 

When dealing with media, it is often the case that content may be subject to 
copyright laws. It is important that the legal implications surrounding all content in 
the system is understood, and where necessary, royalties paid to the appropriate 
parties. 
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Obiect Management (8108) 

Object Management processes are very similar to those involved with Repository 
Management. However, they should promote reuse through specific processes: 

• Design review 

• Classes and components packaging for reuse 

• Common components maintenance and upgrade 
Quality Management (8204) 

Quality Management is described at length in the Business Integration Methodology 
(BIM). 

The Quality Management processes are covered by the following tasks: 

• 0623 - Define Quality Management Approach 

• 0732 - Implement Quality Management Approach 

The objective of these tasks is to ensure that, early in the life of a program, program 
leadership explicitly defines what quality means for the program. This results in the 
production of the quality plan. Then the infrastructure and processes are put in place 
to ensure delivery of a quality program. 

The Quality Management Approach defines the following processes: 
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• Expectation Management 

• Quality Verification 

• Process Management 

• Metrics 
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10 Expectation Management Process 

Expectations can be thought of as quality objectives expressed in measurable terms 
such as: 



• Functionality 

• Reliability 



15 • Usability 



• Efficiency 
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• Maintainability 

• Portability 

• Security 

Quality Verification Process 

The targets for quality verification should be defined. Processes and deliverables are 
key candidates. 

In development terms, the V-model is the preferred method by which the quality 
verification process is managed. The V-model ensures that deliverables are verified, 
validated, and tested. It is based on the concept of stage containment (enforcing for a 
given deliverable the identification of the problems before it goes to the next stage) 
and entry and exit criteria (describes conditions in which a deliverable passes from 
one stage to another). 

The quality verification process owner may not be responsible for executing the V- 
model, but is responsible for making sure that the V-model is in place and complied 
with. 

Metrics Process (8110) 

To fine-tune the development process, the important quality attributes must be 
measured. Sample metrics include: 

• Development environment availability 
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• Time needed for a new user to learn to use a function of the development 
environment 

• User error rate per function 

• User satisfaction per function 

• Code complexity 

• Code structure 

• Productivity 

• Average number of defects per design packet at the moment construction starts 

• Average number of defects per program at the time of its first migration to 
system test 

Once the key metrics are agreed upon, procedures must be put in place to: 

• Perform the measurements (these should flow from the development processes 
in a natural way) 

• Compare results with the goals documented in the quality plan 

• Analyze deviations, with key focus on the process that caused the deviation 

• Adjust the processes so that similar deviations do not occur in the future 
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Continuous Improvement Process (f&\\2) 

The first stage of the Continuous Improvement Process (CEP) is to capture 
continuous improvement opportunities. These may include: 

• Gaps identified by metrics 

• Analysis of program performance-internal quality verification results 

• Process reviews 

• Capability Maturity Model (CMM) assessments 

• Suggestions made by program team members; for example, through a suggestion 
box 

The CIP then plans and manages improvement related activities such as: 

• Define explicit criteria for assigning priority 

• Consider raising the priority of low-priority opportunities that can be completed 
quickly 

• Maintain a mix of high-priority and sure successes to ensure the continued 
momentum 

• of the Continuous Improvement program 

• Define the opportunity selection process 
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• Identify the resource allocation process 

• Define the scheduling process 

• Identify how the effort will be monitored 

• Identify the procedure for communicating results to the organization 

• Establish a continuous improvement organization to support the process 

• Prioritize and classify opportunities 

• Select projects 

• Allocate resources and scheduling 

• Monitor effort 

• Support a standard process improvement process across the project 

While maintaining quality at a program level, the Quality Management team must 
liaise with each of the organizational units within the development environment in 
order to monitor the quality management processes within these units. 

Standards and Procedures 

The Capability Maturity Model (CMM) for Software describes the software 
engineering and management practices that characterize organizations as they 
mature their processes for developing and maintaining software. 
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The CMM provides a software organization with guidance on how to gain control 
over their processes for developing and maintaining software and how to evolve 
toward a culture of software engineering and management excellence. The model 
defines five levels of software process maturity as well as how to move from one 
level to the level above. 

For more details, refer to Consistently Delivering Value: The CMM - How to Help 
Your Project Measure Up 

The V-model is a framework that promotes stage containment by organizing the 
verification, validation, and testing in and across all the methodology elements 
throughout the delivery phase of the Business Integration Methodology. 

For more details, please refer to the V-model overview job-aid in the Business 
Integration Methodology. 

The IMPROVE Job Aid (provided with the BIM Guide) describes the process for 
solving problems or improving a process. In this Job Aid, you will find an 
introduction to the five step process your team can use to solve both simple and 
complex problems. The Quality Action Team (QAT) is responsible for applying 
IMPROVE to improve a process or solve a problem. 

Program and Project Management (8214) 

Program Management 

Program Management focuses on the continuous oversight needed to support the 
delivery of business capability through multiple projects and releases. Appropriate 
disciplines, techniques, and tools are used to plan and organize the work, and to 
manage the incremental delivery of the new business capability. 
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Program Management consists of three major activities, each split into a number of 
task packages. 

a) Plan Program 

• 061 0 - Understand Program Expectations 

• 0620 - Plan Management Processes 

• 0640 - Develop Program Master Plan 

• 0650 - Design Initial Teamwork Environment* 

• 0670 - Plan Delivery 

• 0680 - Create Program Plan 

b) Mobilize Program 

• 07 1 0 - Obtain and Deploy Resources 

• 0730 - Implement Management Processes 

• 0750 - Establish Program Management Office 

• 0770 - Implement Initial Teamwork Environment* 

• 0790 - Establish Orientation and Training 
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c) Manage and Improve Program 



0810 - Direct Program 

0820 - Execute Management Processes 



• 0830 - Analyze Program Performance 

• 0840 - Plan and Implement Program Improvements 

• 0850 - Operate Program Management Office 

• 0860 - Authorize Build and Test 

• 0870 - Authorize Deployment 

• 0880 - Operate Team Work Environment* 

• 0890 - Conduct Program Close-Out 

*The Team Work environment, in the domain of the development environment, 
includes those parts of the development environment which are consistent across the 
entire program (e.g. Collaborative tools) 

Project Management 



Project Management focuses on providing specific deliverables through balanced 
management of scope, quality, effort, risk, and schedule. Project Management 
processes follow a cycle of planning the project's execution, organizing its 
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resources, and controlling its work. The Project Management team oversees all other 
teams within the development environment. 

Project Management comprises a single activity containing a number of task 
packages. 

a) Plan and Manage Project 

• 0920 - Plan Project Execution 

• 0940 - Organize Project Resources 

• 0960 - Control Project Work 

• 0990 - Complete Project 
Configuration Management (8210) 

Configuration Management is not only the management of the components in a 
given environment to ensure that they collectively satisfy given requirements, but it 
is the management of the environment itself. The environment consists not only of 
system components, but also of the maintenance of these components and the 
hardware, software, processes, procedures, standards, and policies that govern the 
environment. 

Configuration Management in systems building consists of four major 
interdependencies : 



• Packaging 
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• Version control 8114 

• Migration control 8116 

• Change control 8118 



Standards and Procedures 

a) Packaging Plan 

Packaging is the combination of systems software and application component 
configurations (source code, executable modules, DDL and scripts, HTML) together 
with their respective documentation. It may also include the test-data, test scripts, 
and other components that must be aligned with a given version of the configuration. 
Packaging allows the grouping of components into deliverable packets of 
application software that can be developed, tested, and eventually delivered to the 
production environment. Packaging defines the underlying architecture that drives 
version, change, and migration control. Each of these control processes defines how 
changes to configuration packages are versioned and migrated to the various 
development and test phases in the systems development life cycle. 

A sample packaging strategy would take into consideration some of the following 
factors in determining a unique method to handle a given configuration packet in 
terms of version, change, and migration control: 



• Base package type - identifies the various types of application components that 
are developed during systems building such as executables, JCL, HTML scripts, 
and Java applets. 
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• Package release type - identifies the types of commonality that components can 
have. There are usually four basic types of components that are developed 
during systems building: 

• Technology architecture packages - these packages are developed by the 
Technology Architecture team and are used by all other projects in a program 

• Program-wide packages - these packages are developed by the Application 
Development teams but are used by other projects in the program. They are 
common components that are not owned by the Technology Architecture team 

• Application common packages - these packages are developed by the 
Application Development team and are used internally on the project by 
application developers 

• Application packages - these packages are the most rudimentary of all 
packages developed. They consist of basic application components developed 
by application developer 

• Package platform type - identifies the eventual delivery platform of the 
package. Identifying this early on in development and encapsulating this 
information within the package definition, allows developers to envisage the 
production environment at an early stage during the systems development life 
cycle. 

Given these three basic package definitions, a configuration management cube can 
be defined, which uniquely identifies version, change, and migration control 
characteristics of a given package. The cube can be used to implement a table- 
driven configuration management control system for all software developed on the 
program. The configuration control system consists of version and migration 
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control. Therefore, the cube defines all processes associated with version control 
and migration of a package. 

b) Version Control (9114) 

Version control and compatibility are key considerations when managing these 
packages. Note that version control not only applies to software components, but 
also to all components of a given package, including test scripts, test data, and 
design documentation. It is also of great importance to keep track of which version 
is in which environment. If incompatibilities are discovered, it must always be 
possible to "roll back" to a previous consistent state, that is, to revert to an earlier 
version of one or more components. It must be possible to define releases of a 
configuration - a list of version numbers, one for each component of the package 
which together form a consistent configuration. The smallest unit that can be version 
controlled should be the package as defined in the packaging plan. This ensures that 
the lowest common denominator in all version control activities is managed at the 
package level. 

c) Migration Control (&116) 

A systems building environment can have many development and test stages. On a 
large project these may include: 

• Development and unit test 
20 . • Assembly test 

• System test 
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• Integration test 
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• User acceptance test 

Migration of packages or consistent configurations from one stage to another is a 
central part of Configuration Management. The key to successful migration is the 
knowledge of what constitutes each stage. Examples of migration include: 

• Migration from development and unit test to system test 

• Migration from user acceptance test to production 

• Migration of development tools from the Technology Architecture team to the 
developers on the project 

• Migration of architecture components from the Technology Architecture team to 
the developers on the project 

Stages and their constituents exist as a result of certain user and technical 
requirements. The technical requirements are derived from the user requirements. It 
is crucial to develop a migration plan that maps out the progression on configuration 
packages throughout the systems development life cycle. Figure 86 is an illustration 
showing a model migration plan in accordance with one embodiment of the present 
invention. 

The Figure 86 model allows the development and testing of architecture components 
independent of application components. The Technology Architecture team can 
develop 8600, assembly test 8602, and system test 8604 their components before 
delivering them to the development environment for the application developers. 
This ensures that the architecture is thoroughly tested before being used by the 
Application teams. The model also illustrates the progression of architecture and 
application components through the systems development life cycle. The application 
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developers can then develop 8606, assembly test 8608, and system test 8610 their 
components before user acceptance tests 8612. The model is a temporal one and 
thus suggests that architecture must be present at a given stage before the 
introduction of application components. 

The version control plan must align with the migration control plan. The version 
control plan defines the points where version control activities will take place. In 
the above example, version control will take place at the development stages, 
architecture development and unit test, and application development and unit test. 

Migration control defines how these version control configuration packages will be 
migrated successfully from one stage to the next until the package is eventually 
released to the production environment. 

d) Change control 

Change requests as a consequence of changing requirements and changes requested 
due to nonconformities (or defects), either in the application software, or in the 
system software must be analyzed, authorized, scheduled, staffed, and tracked in a 
defined way. What, why, when, and who made a change must be tracked from the 
point of analysis to the reintroduction of the defective or changed component at the 
appropriate stage. Change control therefore governs what software component is 
changed, version controlled, and when it is remigrated to a given development stage. 

It is important to link the general change request with the requests produced during 
formal testing phases. This makes the processes clearer. 

Configuration Management becomes more complex in a component-based 
development environment as the system is broken down to a greater level of 
granularity. 
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Release Management (8208) 

Release Management involves coordinating activities that contribute to a release (for 
example, cross-project management) and the coordination of products that 
contribute to a release (such as architecture, integration, and packaging). It is 
concerned with managing a single release rather than cross-release management. 

The Release Management approach documents critical decisions regarding the 
management, tracking, and integrity of all components and configurations within a 
given release. The Release Management approach must be closely coordinated with 
the definition of the Configuration Management approach and the Problem 
Management approach. Release Management involves two main components: 

• The coordination of activities that contribute to a release 

• The coordination of products that contribute to a release 

The coordination of products that contribute to a release is the maintenance of a bill 
of materials for a release. It is an inventory of all software and hardware 
components that are related to a given release. The development environment is 
directly affected by the Release Management strategy. The way a program decides 
to plan releases affects the complexity of the development environment. 

It should be noted that delivering a system in a series of releases significantly 
increases the effort. 

Standards and Procedures 

If the release plan dictates that there will be parallel development of two releases of 
software, the development environment and configuration management must be able 
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to support the release plan. In the most general development case, a program can 
have a single release capability mechanism 8700 but must simultaneously perform 
maintenance activities 8702 for components that are in production 8704. There must 
be an ability for the program to design, build, and test the applications for 
production. Figure 87 is an illustration showing a single release capability 
development pipeline in accordance with one embodiment of the present invention. 

The ability to perform all development stages for a given release can be defined as a 
development pipeline. The pipeline consists of all development and testing stages 
necessary to release the software to production. 

The pipeline strategy of a program depends directly on the release strategy. A 
program is potentially developed on three different timelines: 

• Short term 8800 - production bug fixes 

• Middle term 8802 - production service packs 

• Long term 8804 - new releases of software 

To support this release plan, the development environment must be separated into 
pipelines that are replicas of a single migration path to production 8704. A pipeline 
consists of all the necessary development and testing stages required to deliver a 
piece of software to production. Therefore, because of simultaneous development 
and testing of three code bases, there needs to be three development and testing 
pipelines that deliver software to production. 

The pipelines must be capable of allowing the developer to design, build, and test 
applications as well as architecture components. Figure 88 is an illustration showing 
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a multiple release capability development pipeline in accordance with one 
embodiment of the present invention. 

As can be derived from the above illustrations, the more flexible a release plan, the 
more complex the development environment. As the number of development 
5 pipelines increase, the complexity of working in the development environment also 
increases. All development environment tools must support the pipelining strategy 
and so must the configuration management and problem management processes. 

The pipeline strategy for a program must incorporate code base synchronization. 
Code base synchronization must occur among the three pipelines to ensure that the 
three code bases eventually result in one version in production. Figure 89 is an 
illustration showing a multiple release capability development pipeline with code 
base synchronization among three pipelines. 



Environment Management (8206) 

15 Since the development environment is a production environment, it follows that 
environment management must be planned, organized, and executed to ensure a 
predictable and productive environment. Andersen Consulting has a comprehensive 
framework for the Management Of Distributed Environments (MODE). It describes 
four central functions: 

20 • Managing Change 8120 

• Service Management 8122 
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• Service Planning 8124 
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• Systems Management 8126 

MODE provides an excellent framework for specifying the management 
responsibilities that apply to the development environment. These responsibilities 
are often assigned to the technical group, but as discussed above, there are benefits 
associated with establishing a dedicated environment management team. 

The Environment Management component described here uses MODE as a 
framework, adopts MODE terminology, and focuses on those management tasks, 
which are particularly important in the development environment. 

Adopting a structured approach to environment management, which applies the 
same principles to development as it does to production, has several advantages: 

• High-quality support for developers 

• Significant experience with the operations management tools in an environment, 
which is generally smaller and which carries lower risk than the full production 
environment 

• The ability to tune the environment management approach before production 
roll-out 

In some respects, the development environment is simpler than the production 
environment. It is, for example, generally smaller in terms of the number of 
hardware components and the number of locations. In other respects, however, the 
development environment is more complex. For example, the amount of change in 
this environment is generally higher than in the production environment. In fact, the 
environment can be so fluid that extreme care must be taken to maintain control. On 
a large engagement, one dedicated technical support person per ten designers and 



- 123 - 



programmers is recommended. The greatest need for technical support is generally 
during detailed design and programming. It is, however, necessary to start building 
the technical support function before detailed design. 

All processes that are performed by the Environment management team must be 
documented in a centralized database that allows quick and easy reference. 

Service Management (8122) 

Service Management provides the interface between the Environment Management 
team, the Development teams, and external vendors or service providers. It manages 
the level of service that is provided to the developers. In order to maintain this 
service, three areas must be managed: 

• Management of Service Level Agreements (SLAs) 

• Management of Operations Level Agreements (OLAs) 

• Help Desk 

Service Level Agreements 

In order to plan and organize the development work appropriately, a Service Level 
Agreement (SLA) must be in place between the Service Management group 
(typically part of the Environment Management team) and the developers. As with 
all other components of the development environment, this agreement should be 
kept simple. It should specify the following: 

• The responsibility of the Environment Management team 
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• How developers should request technical support 

• How quickly a request for support will be serviced 

• How the Environment Management team will notify developers of environment 
changes such as changes to databases and common technical modules 

Specifications of service levels should be precise and the service must be 
measurable. The SLA should also specify how to measure this service (for example, 
system response times, request service times, backup frequencies). In addition, the 
SLA must be managed. It may have to be modified as the environment changes, and 
it must be reviewed with developers on a regular basis to see if the service level is 
adequate. 

a) Operations Level Agreement Management 

The Environment Management team is responsible for providing the specified level 
of service, but frequently relies on external vendors and suppliers to perform certain 
tasks. For example, hardware service is typically provided by the hardware vendor. 
To provide the agreed level of service to the developers, the Environment 
Management team must ensure that external vendors provide their services as 
required. This generally means establishing a contract with the vendor and 
following up that the contract is respected. 

As the relationship between the Environment Management team and external 
vendors becomes less formalized (for example, Internet Service Providers, mass 
market software vendors), it becomes more difficult to provide guarantees on the 
level of service that will be delivered. 
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b) Help Desk 

The Help Desk function is an important part of the interface between the Service 
Management group and the developers. The Help Desk makes sure that questions 
are answered and requests serviced in a timely manner by the right people. In a 
complex, leading-edge environment, the Help Desk is crucial to maintaining 
productivity. The Help Desk needs particular focus when: 

• The system software is immature 

• The development environment is weakly integrated 

• The environment is heterogeneous 

• The amount of newly released custom infrastructure is large 

• The developers are less experienced 

While supervisors and coordinators who work with the developers may alleviate the 
impact of these factors, the more difficult questions must be resolved by the 
Environment Management group. As some of these will be repeat questions, the 
ability to log the question, the analysis, and the result in a structured way provides 
the basis for performing smart searches and answering the question quickly. Repeat 
questions may also trigger: 

• Additional training 

• Modifications of existing training 

• Additional entries in a "technical hints" database 
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• Changes in tools, procedures, and responsibilities 

Efficient searches in the Help Desk database can, in some cases, be greatly 
facilitated by extending the basic functionality of the Help Desk tool. This can be 
achieved, for example, by adding a smart word search capability on top of the Help 
Desk history database. 

Comprehensive training must be given to Help Desk personnel in order to ensure the 
best possible level of service to the developers. 

In addition to serving internal project needs, the Help Desk must be prepared to 
coordinate the activities of external suppliers to solve problems. This occurs when 
several new versions of hardware and system software are introduced, and 
compatibility issues arise. Part of the coordination is the tracking of request IDs, 
which refer to the same question but which are assigned differently by each supplier. 

To manage communication with external vendors, a contacts database with the 
following information is useful: 

• Company name 

• Products supplied 

• " Details on support arrangements 

• Address, phone and fax numbers 

• Main contact 



• Secondary contacts 
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• Regional office address/fax/phone/contacts 

• World headquarters address/fax/phone/contacts 

Based on this information, it is useful to log the exchanges with the external 
company, indicating: 

• Date 

• Individuals involved 

• Key information exchanged 
c) Quality Management 

Defining the SLA, with its specific, measurable criteria, is the basis for continuous 
improvement. The continuous improvement effort may focus on providing the same 
level of service with fewer resources, or on providing better service. An important 
part of quality management is ensuring that the Environment Management team 
understands the key performance indicators for service delivery, that these indicators 
are monitored, and that all personnel are adequately equipped with the tools and 
training to fill their responsibilities. While the entire team is responsible for 
delivering quality, the responsibility for Quality management should be assigned to 
a specific individual on the Environment Management team. 

Systems Management (8126) 

MODE divides Systems Management into: 

• Production control 
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• Monitoring 

• Failure control 

• Security management 

• Staffing considerations 
Production Control 

In the development environment, a number of activities must be performed 
according to schedule, including: 

• Reorganization of databases, including the repository 

• Rerunning of database statistics 

• Performing backups 

• Transportation of backups off-site 

• Performing periodical file transfers between environments/sites 

• Preventive maintenance of equipment 

Many of these activities can be scheduled and performed automatically, but must 
have some level of manual control to ensure that they are executed correctly. 
Control tasks may include checking and archiving activity logs. Standards and 
procedures that describe the control function must be established. 
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Monitoring 

The Environment Management team must systematically monitor the development 
environment to ensure that it is stable, provides adequate response times, and 
satisfies the needs of the developers. This monitoring involves looking at trends and 
extrapolating them to anticipate problems with disk capacity, system performance, 
network traffic, and so forth. 

Failure Control 

Failures must often be corrected quickly to restore service. The time needed to 
restore service is affected by the time it takes to isolate and repair the fault. In many 
cases, elapsed time can be shortened by allowing remote administration of system 
components. 

Security Management 

Security management involves: 

• Defining security requirements 

• Preventing security breaches 

• Limiting the effect of security breaches 

• Detecting security breaches 

• Correcting the effect of security breaches 
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Although direct sabotage is rare, inexperienced developers, perhaps new to the 
project, can wreak havoc to the system under development by inadvertently deleting 
or modifying system components. Focus must be on defining access rights so that 
developers have the right level of access (read/write) to all the information that is 
useful and relevant to their work. 

With the opportunity to connect development environments to the internet comes 
new risks. There is a potential for security breaches or the transfer of viruses and 
other malicious programs. In extreme situations, where security is of great 
importance, it may be prudent to isolate the development environment, and allow 
Internet access only via a dial-up connection on stand-alone machines. The overlap 
of responsibility for Security Management between the Environment Management 
team and the Security Management team will need to be defined at the program 
level. 

Outsourcing Considerations 

In the development environment, it may be possible to outsource certain Systems 
Management tasks. For example, the LAN supplier may be willing to take 
responsibility for LAN support, upgrades, and so on. Similarly, an existing data 
processing center may be willing to take responsibility for host operations. Such 
agreements are very beneficial and make it possible to use project team members 
more effectively. However, outsourcing the development environment carries a risk, 
which can be mitigated by defining a Service Level Agreement with the provider. 
This will generally be very similar to the SLA established between the Environment 
Management team and the developers. One important difference is that punitive 
measures (to be applied if the SLA is not respected) must be specified to ensure that 
outside suppliers are strongly motivated to abide by the agreement. 
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Service Planning (8124) 

MODE divides Service Planning into: 

• Service Management Planning 

• Systems Management Planning 

• Managing Change Planning 

• Strategic Planning 

All these planning stages apply in the development environment and are analogous 
to the kind of planning that must occur in the business application's production 
environment. One of the most important success factors when providing technical 
support is being proactive and anticipating the need for intervention. 

Service Management Planning 

Once the SLA is defined, the resources required for delivering the service can be 
specified. Questions to address include the staffing of these resources and training 
to ensure that they are equipped to deliver service as agreed. 

Systems Management Planning 

Daily tasks must be specified, assigned, and followed up. Systems management 
planning determines who is responsible and how follow-up is performed. 
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Managing Change Planning 

Managing change planning is of great importance in the development environment. 
During a large project, several very significant changes to the development 
environment must be accommodated. They include: 

• New hardware 

• Rewiring of the network 

• New development software 

• New releases of existing development software 

• New releases of infrastructure components (custom-built technology 
architecture) 

The release of these components into the environment requires very careful planning 
to ensure minimal disruption for developers. Techniques commonly used include: 

• Fallback options if a new component does not function as planned 

• Partial rollout to a subteam to limit the consequences if a component does not 
work as planned 

• Ample information to developers about timeframes for rollout and expected 
effects of new components 



Well planned testing 
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• Sufficient training for new tools or changes to existing tools 

Planning for change includes choosing options based on a thorough understanding 
of the positive and negative impacts of change to the environment. Changes to the 
development environments should be analyzed and planned for as orderly releases 
rather than a stream of small modifications. Changes should be packaged into 
releases, and each new release of the development environment should be tested by 
developing a small, but representative part of the system using the new environment. 
Ideally, this test should be performed by real developers rather than by the 
Environment Management team. This may be very helpful in order to obtain better 
buy-in. 

Strategic Planning 

Strategic planning is traditionally regarded as being less important in a development 
environment than in the production environment, mainly because the development 
environment is often viewed as a temporary entity that does not warrant serious 
strategic considerations. This may be changing however, with the concept of the 
enterprise-wide development environment - a single, generic development 
environment architecture that is tailored to each specific project. In this case, 
strategic planning for the development environment is vitally important if the 
environment is to evolve, and allow the organization to remain competitive. 
Strategic planning of the environment management function may, for example, 
include such questions as support for multisite development and coordination of 
multisourced systems management. 

Managing Change (8120) 



The development environment is subject to constant change (for example, the 
addition of new tools, or changes to code libraries), which needs to be managed 
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carefiilly. The Managing Change component comprises three sub-components: 
Controlling Change, Testing Change, and Implementing Change. 

Controlling Change 

After planning for and scheduling change, it must be controlled. This ties in closely 
with Configuration Management. 

Testing Change 

Thorough testing is required to reduce the risk of productivity loss due to 
environment changes. Techniques commonly used include: 

• Careful scheduling of events to minimize disruptions (typically weekends and 
evenings are used to enable a strictly controlled test of new components released 
to the design and construction environment). 

• Rigorous testing of Environment Management tools themselves. This test must 
be as rigorous as the testing of the execution environment. 

• A hardware and systems software acceptance test environment where 
components from external suppliers are validated before the component is 
accepted into the environment. 

• One or more separate architecture build and test environments where new or 
modified custom-built components can be thoroughly verified before they are 
made available. 

In addition to reducing risk, testing should also verify that the expected positive 
benefits of the change are indeed obtained. 
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Implementing Change 



After planning and testing the change to be introduced, it must be implemented. The 
most common kinds of change in the development environment are the introduction 
of additional hardware, new releases of databases, subroutines and infrastructure, 
5 and upgrades to tools. Each change implementation should be viewed as continuous 
improvement so that any difficulties or inefficiencies are analyzed and resulting 
improvements are planned and implemented. To be effective over time, this 
requires that procedures be documented and regularly reviewed and enhanced. 

□ 

4* When the database is changed, new versions of test-data must be developed and 

A 10 distributed. When infrastructure components are modified, they may have to be 
~ distributed across platforms, and the ripple-effects (for example, the need for 

si si. 

M- recompilation or code changes in affected components) must be understood and 

l a coordinated. Some projects have experimented with incentives to ensure that the 

J| infrastructure components do not change too frequently. One such strong incentive 

fL£ 15 is to make the Architecture team responsible for all ripple effects and have them 

^ implement all the application level changes that result from an architecture 
modification. 



Problem Management (8212) 



Problem Management is generally associated with the discrepancies that result from 
20 the testing process, though it may also be applied to the management of design 

problems detected during verification or validation steps. Problem Management is a 
crucial process in the system development life cycle. It ensures that quality software 
is designed, developed, and tested so that initial benefits defined in the business case 
are in fact realized. A development environment must have a formally defined 
25 problem management process to ensure that this objective is met. 
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Formal problem tracking helps to control the analysis and design process by 
maintaining documentation of all problems and their solutions. Problem tracking 
improves communication between developers and business representatives, which is 
particularly helpful in minimizing misunderstandings at later stages of the 
development cycle. 

Such formal problem tracking also helps to facilitate the solution process by 
formalizing a procedure for reviewing, acting on, and solving problems in a timely 
manner. By circulating problem documentation to all affected parties, management 
can minimize the risk of misunderstandings at a later date. In addition, the 
documentation serves as an audit trail to justify design and implementation 
decisions. 

It is, however, important to note that not only the software that is developed for 
business case benefits realization must have a formal problem tracking mechanism, 
but the development environment architecture must also have a formal problem 
tracking mechanism. The development environment tools and processes support the 
design, development, testing, and delivery of quality software. Therefore, the 
foundations of design, build, and test must be stable and problem free. All problems 
identified in the development environment architecture must be tracked formally and 
solved as the development environment is also a production environment for 
developers. 

System Building (8218) 

Understanding the systems building process is important since well defined 
development tasks and workflows form the basis for achieving high productivity and 
consistent process quality. Tools to support these processes may be found in Tools - 
System Building . 
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The development environment varies by segment of a systems development project. 
The following model is used when discussing different components of the 
development environment. 

The development process is iterative and can be entered at different stages 
depending on the complexity of the changes. Small corrections may not require 
explicit design, and small enhancements may not require any high-level design. The 
shaded, elliptical labels in the above figure indicate how the development process 
can be entered depending on the magnitude of the change. 

The iterative nature of the development process is important since it implies that 
components of the development environment, which are put in place for design (for 
example), must be maintained, since they will continue to be used until the end of 
system test and beyond. Multiple releases of the business application may also be 
under concurrent development at different stages. This may lead to very active use 
of design, construction, and testing tools at the same time. 

Analysis & Design (8128) 

Analysis and design in this context, refer to the two Business Integration 
Methodology activities: 

• Design Application 

• Design Technology Infrastructure 

The most critical and perhaps the most difficult work occurs up front. The success 
of the entire design effort depends on the quality of the work performed to gather, 
document, communicate, and analyze requirements in the early stages. Standards 
for how to document these requirements are very important. They facilitate 
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communication, which, in turn, ensures a common view of the problem to be solved. 
Communication must be ensured within the analysis team but also with the (possibly 
future) designers and programmers. 

Tool support may help enforce standards, and such tools are discussed under Tools - 
System Building - Analysis & Design 

The design process includes numerous activities, which range from high-level 
general considerations to low- level detailed issues. The overall objective of design 
is to transform functional and technical specifications into a blueprint of the system, 
one that will effectively guide construction and testing. While requirements analysis 
and specification deals with what the system must do, design addresses how the 
system will be constructed. Validating that the design actually meets the 
requirements for functionality, performance, reliability, and usability is essential. 

The quality of the design process directly affects the magnitude of the efforts 
required to construct and test the system, as well as the maintenance effort. 
Investments in defining high-quality design standards and procedures and 
integrating tools is therefore particularly important. It may, for example, have a 
direct impact on the degree of reuse achieved. In addition, adequate training must 
be provided to ensure that the designers make optimal use of the environment 
provided. 

Information on how to approach system design can be found in the following 
Andersen Consulting sources: 

• Delivery Vehicle Frameworks 

• Network-Centric Architecture Framework 
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• The Graphical User Interface Design Guidelines 

• Design Application Architecture 

New tools and processes link detailed design and construction more closely than 
before. To realize the expected benefits from repositories and code generation, the 
output from detailed design must be exact and correct, leaving little room for 
interpretation. This requires careful quality control and very specific exit criteria 
associated with the completion of detailed design. 

It is important that the development environment accommodates concurrent effort in 
different areas. For example, parts of design may occur after system test starts, as in 
the case of an urgent change request, or when a significant inconsistency is detected 
in system test. Some reverse engineering work may also occur before design or 
during construction. 

When standards, procedures, and tools are developed for a task, it is important to 
consider where the task belongs in the sequence of tasks that contribute to the 
development. For example, the use of a repository early in the development process 
reduces the need for re-entering information while enhancing consistency and 
facilitating standards compliance. 

Usability and User Interface Design 

Usability is an important (and often overlooked) consideration in system design. 
Usability is more than a well-designed user interface - the way in which business 
processes are modeled, how they are implemented within the system, and how they 
are presented to the user all contribute to the overall usability of the system. 
Usability is an iterative process of refinement that results in systems that are easy to 
learn, efficient, and enjoyable. In the very broadest sense, usability is the thoughtful, 
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deliberate design approach that considers users throughout the solutions-building 
process, from start to finish. For this reason, usability guidelines should be defined 
and followed at every stage of system design. This, along with regular usability 
reviews and tests both internally, and by target user groups (by using prototypes), 
helps to reduce the risk of a poorly received system. 

The User Interface has become increasingly important as systems become more and 
more user-facing. As multimedia technologies evolve allowing the development of 
richer user interfaces, so the design processes must adapt to reflect these new 
technologies. The processes that surround the design of media content are similar to 
that of regular system design, and many of the same issues that apply to designing 
traditional user interfaces also apply to the design of media content. The major 
change is the involvement of media content designers - a group of people not 
traditionally associated with system design and development. As their presence is 
relatively new to the scene of systems development, it is often the case that media 
content designers are not fully integrated into the development team - a potentially 
costly mistake. It is important to ensure that media content designers are involved in 
the design process at a very early stage, and that they are fully integrated into the 
application design and construction teams. 

The approach to Interface design is evolving as media technologies become more 
advanced. Modem media creation tools allow the development of not only media- 
rich interfaces, but also the functionality that lies behind them. This means that the 
role of the media content designer may now range from that of designing the look 
and feel of a user interface, to developing the entire presentation layer of an 
application. In this situation, the role division between media designer and 
application developer becomes a difficult one to define, reinforcing the argument for 
fully integrating media designers into the application development team. 
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Standards and Procedures 

Well documented, comprehensive standards make designers more independent and 
enable them to produce more consistent, high quality designs. Common standards 
include: 

• Detailed specifications of deliverables from each design step 

• Window and report design standards 

• Naming standards for design objects and documents 

• Navigation standards 

• Standards that specify the design techniques to use 

( . 

• Documentation standards that specify format 

• Technology infrastructure design standards that specify how to ensure security, 
handle errors, and manipulate context data 

While the standards focus on what to do during design, procedures focus on how to 
doit. Procedures must be in place to specify: 

• How to resolve functional and technical issues 

• Which tools to use and how to use them 

• How to perform design validation 
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• When and how to initiate and perform functional and technical design reviews 

• How to cope with design teams distributed across locations* 

Guidelines give assistance in areas where judgment is important and where 
standards are not easy to define. Valuable guidelines may include: 

• Usability guidelines 

• Style guidelines 

• Guidelines on how to use a tool effectively 

• Sample design packet for each kind of system component to be designed 

Designers must understand standards and procedures other than the ones listed 
above. For example, repository related standards are very important to designers. 
These standards are discussed in Processes - Information Management 

Implementation Considerations 

a) Multi-site Development 

In the case of systems being developed by multiple parties or across multiple 
locations, it is vital that a process of regular communication is implemented. This 
communication should involve all the parties involved in the design of the system, 
and is usually conducted in the form of an audio conference. Through this process, 
it must be ensured that all parties are approaching problems from the same direction, 
and that they are thinking about the design in the same way. If this is not achieved, 
there is great potential for misunderstanding across teams, which generally leads to a 
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badly integrated system. In this type of situation, where parties are not working 
together on a day to day basis, it is also important that any definition (requirements 
or design) is completely free of ambiguity (if anything is left open to interpretation, 
there is a high risk that it will be misinterpreted). Practically, this means that quality 
5 controls on documentation need to be more stringent than on a traditional single-site 
project. 

Reverse Engineering (8130) 

Reverse Engineering is a set of techniques used to assist in reusing existing system 
components. Most of the time, this work is performed manually: one person studies 
thick listings to understand data layouts and processing rules. The person gradually 
builds a higher-level understanding of how the components work and interact, 
effectively reverse engineering the system into a conceptual model. It may be 
necessary to study certain pieces of code to understand how they work, but reverse 
engineering is not limited to code. For example, these techniques might help 
understand the data-model of a legacy application, in order to better design the new 
applications that will coexist with it. 

The process can be very time-consuming and is notoriously difficult to estimate. 
Tools to support the effort do exist, and have been used successfully to streamline 
the process. The main problem with such tools, however, is the hasty (and 
20 erroneous) conclusion that tools automate everything. They do not, just as design 
tools do not automate the design process. Human intelligence is still required to 
drive the effort. 

The supporting tools can, however, reduce the amount of manual effort needed and 
significantly lessen the amount of non value-added activities, such as "find all the 
25 places in a program that affect the value of a given variable". 
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The goal of a specific reverse engineering effort generally falls into one of the 
following categories: 

• To determine which parts of existing systems must be replaced and which can be 
reused 

• To determine how a particular component works in order to design other 
components that interface with it 



• To extract components for reuse 

• To prepare for cleaning up those parts of a system that will be retained 

In component-based development, a concept known as "round-trip reengineering" 
provides the developer with a way of modifying a component model and generating 
the code, then at a later date modifying the code at predefined locations in the source 
code and regenerating, thus enabling the model to maintain a 2-way- 
synchronization. 

Note that components to be reverse engineered can be both part of a custom-built 
system, or part of a software package. 

Projects dealing with the Year 2000 issues have had much experience in 
reengineering. 

Standards and Procedures 

The following reverse engineering guidelines should be used as input when 
developing standards and procedures for a particular context. 
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• Reverse engineering can provide important input both to the design process and 
to the construction process. Timing of the activities is therefore important. 

• The interplay between design and reverse engineering can be intricate: a high- 
level design is needed to determine which components from existing systems are 
of interest. Once this is determined, these components can be extracted, 
generalized, and fed into the detailed design process as one source of 
information. 

• The value of reuse will vary with the functional and technical quality of the 
code. 

• It may be useful to clean up existing code before it is extracted for reuse. 

• Tools should be chosen based on knowledge of the system, the amount of code 
to be processed, and the experience of the personnel involved. 

• The end should be kept in mind. With powerful tools, it may be tempting to 
"investigate for fun" rather than extracting what is needed. 

• As with all other tools, adequate training is important. 
Packaged Component Integration (8132) 

Packaged Component Integration applies to the use of any third party (or previously 
developed) technical components that may be integrated into the target system. This 
can range from simple components offering limited functionality (worksheet or 
charting GUI components), to components handling a significant portion of the 
application architecture (data access components and firewalls). The process 
involves a number of stages: 
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• Package or Component Selection 

• Component Customization 

• Component Interfacing 
Standards and Procedures 

A proven practice in the component-based development world, when dealing with 
purchased components, is to "wrap" them, i.e. encapsulate them so that the visible 
piece of any component remains fully controlled. This way, when a component is 
replaced (either for an update or because it has proved to be defective), no other 
system components that refer to that component will need to be altered. 

Construction (8134) 

Construction covers both generation of source code and other components as well as 
programming and unit test. It may also involve help text creation and string test. 

As construction is a large part of system building, the benefits of streamlining this 
process are significant. Since several aspects of construction are rather mechanical, 
it is often fairly easy to simplify this process and to automate parts of it, particularly 
if the design holds high quality. 

The arrival of Integrated Development Environments (IDEs), has further simplified 
the automation of construction processes to the degree that a single tool can manage 
the majority of the process. 

As with Analysis and Design, usability must not be ignored in the construction of a 
system. Especially in the case of an iterative development approach, it is vital that 
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those responsible for usability and target user groups are involved in regular reviews 
as the system is being developed. 

Standards and Procedures 

Important standards include: 

• Programming standards for each programming language, including procedural 
languages, job control languages, and data access languages 

• Test documentation standards 
Important procedures include: 

• Code generation procedures, including pre-processing of the code shell and post- 
processing of the generated code 

• Testing procedures 

• Test-data handling and common test-data usage 

• Procedures for functional and technical reviews 

• Code review checklist 

• Migration procedures which specify how to make common modules public 




Important guidelines include: 
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• Usability guidelines 

• Shell usage guidelines 

• Tools usage guidelines 
Test (8136) 

System test is performed to validate that the gathering and transformation of 
information is complete and correct. 



As automation progresses and an increasing number of business processes are 
supported by computer systems, system test is changing in nature. Firstly, the 
testing of interfaces to other systems is becoming an ever larger part of systems test. 
Secondly, system test increasingly applies to a new release of an existing system. In 
addition, it is worth noting that as design and construction is increasingly automated, 
system test is becoming a larger part of the total development effort. 



Both of these factors increase the value of automated testing tools, given that the 
work associated with checking that system changes do not have unintended side- 
effects, is becoming an ever larger part of system test. Another trend affecting 
system test is the demand for traceability. Increasingly, users and management 
wish to know the purpose of a given test condition. This is answered by referring 
back to the design and to user requirements. 



System test is a very large part of any systems development effort and can, 
especially when requirements are changing, exceed one third of the entire effort. A 
streamlined environment, which enables high productivity is therefore of utmost 
importance. 
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IMPORTANT: When planning system test, it is vital that the testing of all target 
platforms is included in the test plan. For each platform that is supported by the 
system, there must be a separate set of tests. 

The necessity of impact of volume and stress testing early in the development 
process is becoming more common, due to the proliferation of new technologies and 
tools which have little or no performance track record. It is important that the 
performance and reliability of such tools and technologies is established as early as 
possible in the project to avoid possible problems further down the line. 

Component-based development may have an impact on the way in which testing 
should be performed. 

Standards and Procedures 

System test relies heavily on configuration management, repository management, 
and quality management. 

• Configuration management provides the basis for promoting a configuration 
from the construction environment to the system test environment. As test 
cycles are run and fixes implemented, migration can become complex, requiring 
flexible mechanisms for locking and unlocking system components and 
analyzing the impacts of change. 

• Information management, and in particular repository management, guarantees a 
correct view of the interrelationships between system components. This is 
required to ensure that impact analyses are complete and correct, which, in turn, 
makes for effective regression testing. 
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• Quality management, together with well-defined standards and procedures, 
ensures that the outputs from each test activity are documented at the right level 
of detail and fed back to the design and construction teams, in accordance with 
the quality plan. 

Each of the following system test activities needs well-documented standards and 
procedures and should be supported by tools: 

• Promote configuration (migrate configurations from the construction 
environment to the system test environment) 

• Run test cycle 

• Compare expected results and actual results 

• Log System Investigation Requests (SIRs) 

• Analyze deviations and identify components requiring change (either expected 
results, test-data, or system components) 

• Define Change Requests (CRs) and perform impact analysis 

• Package those change requests that affect the same areas and that naturally 
belong together, into change packages 

• Schedule and staff the changes 

• Unlock components for change 
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• Perform changes and refine impact analysis based on added understanding 

• Verify changes before re-submitting to system test 

• Migrate to system test based on updated impact analysis and re-lock components 
Implementation Considerations 

a) What model of testing does the firm follow? 

The following is an overview of the firm's testing methodology as documented by 
RTP. It describes the framework for the testing process, or the V-model of 
verification, validation, and testing. 

b) Are program specifications being tested? 

The following is an overview of the component test as documented by RTP. It 
describes the testing methods used to validate the detailed design stage where 
program specifications are tested. 

• Component Test - A component test is the testing of an individual piece of the 
solution. All components, including application programs, conversion programs, 
and input/output modules, are subject to component test. The objective is to 
ensure that the component implements the program specifications. At the end of 
component test, all lines of code should have been exercised, keeping in mind 
the specified functional and quality requirements. 
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c) Are systems design being tested? 

The following is an overview of the assembly test as documented by RTP. It 
describes the testing methods used to validate the technical design stage where 
system designs are tested. 

• Assembly Test - The assembly test tests the interaction of related components to 
ensure that the components, when integrated, function properly. Assembly test 
ensures that data is passed correctly between screens in a conversation or batch 
process and that messages are passed correctly between a client and a server. 
The specification tested is the technical design. The application flow diagram 
within the technical design depicts the assemblies, either on-line conversations 
or batch assemblies, that will be assembly tested. Testing is therefore organized 
by assembly rather than by business function. 

By the completion of assembly testing, the system should be technically sound, and 
data flow throughout the system should be correct. Component and assembly 
testing ensures that all transactions, database updates, and conversation flows 
function accurately. Testing in later stages will concentrate on user requirements 
and business processes, including work flow. 

d) Are benefits being tested? 

e) Are costs being tested? 

j) Are intangibles being tested? 

The following is an overview of the benefits realization test as documented by RTP. 
It describes the testing methods used to validate the business case stage where 
benefits, costs, and other intangibles are tested. 
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• Benefits Realization Test - The benefits realization test tests that the business 
case for the system will be met. The emphasis here is on measuring the benefits 
of the new system, for example: increased productivity, decreased lead times, or 
lower error rates. If the business case is not testable, the benefits realization test 
becomes more of a buyer signoff. 

Ideally, benefits realization test occurs prior to complete deployment of the system 
and utilizes the same environment that was used for the service-level test piece of 
operational readiness test. Tools are put in place to collect data to prove the business 
case (e.g., count customer calls). A team of people to monitor the reports from the 
tools and prove that the business case is achieved is still needed. The size of the 
team depends upon the number of users and the degree to which tools can collect 
and report the data. The benefits realization test tests that the business case for the 
system will be met. The emphasis here is on measuring the benefits of the new 
system, for example: increased productivity, decreased lead times, or lower error 
rates. If the business case is not testable, the benefits realization test becomes more 
of a buyer signoff. 

g) Are quality requirements being tested? 

h) Are technical requirements being tested? 

i) Are functional/user requirements being tested? 

The following is an overview of the product and operational readiness test as 
documented by the RTP. It describes the testing methods used to validate the 
requirement/definition stage where quality, technical and functional/user 
requirements are tested. 
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• The Product Test - The product test tests the entire application to ensure that all 
functional and quality requirements have been met. Product testing may occur at 
multiple levels. The first level tests assemblies within an application. The next 
level tests applications within a system, and a final level tests systems within a 
solution. Within the multiple levels, the purpose is the same. 

The product test tests the actual functionality of the solution as it supports the user 
requirements: the various cycles of transactions, the resolution of suspense items, the 
work flow within organizational units and among these units. The specification 
against which the product test is run includes all functional and quality requirements. 
The testing is organized by business function. 

• The Operational Readiness Test - The objective of the operational readiness test 
is to ensure that the application can be correctly deployed. The operational 
readiness test is also commonly known as the readiness test, roll-out test, release 
test, or the conversion test. The operational readiness test becomes especially 
key in client/server environments. It has four parts: 

• Roll out test - ensures that the roll out procedures and programs can install 
the application in the production environment. 

• Operations test - ensures that all operational procedures are in place and 
acceptable, and that the production system can be operated by the personnel 
responsible for supporting production. 

• Service level test - ensures that once the application is rolled out, it provides 
the level of service to the users as specified in the Service Level Agreement 
(SLA). 
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• Roll out verification - ensures that the application has been correctly rolled 
out at each site. This test, developed by the work cell or team performing 
operational readiness test, should be executed during each site installation by 
the work cell or team in charge of the actual roll out of the application. 

The operational readiness test assumes a completely stable application and 
architecture in order for it to be successful, and therefore, is heavily reliant on the 
previous testing stages. 

The operational readiness test is the point in the development process where all the 
application development, architecture development, and preparation tasks come 
together. The operational readiness test ensures that the application and architecture 
can be installed and operated in order to meet the SLA. 

DEVELOPMENT TOOLS FRAMEWORK 

Figure 90 is an illustration showing a Development Tools Framework in accordance 
with one embodiment of the present invention. The development environment is 
built upon an integrated set of tools and components, each supporting a specific task 
or set of tasks in the development process. As with processes and organization, the 
central component, System Building, is supported by the eight management 
components: 

• Information Management tools 8202 manage the information that supports the 
entire project - information that is used both in systems building and in other 
management processes 

• Security Management tools 8216 enable the development of security 
components 
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Quality Management tools 8204 support all quality management processes 

Program and Project Management tools 8214 assist the management teams in 
their daily work 

Environment Management tools 8206 provide the facilities to maintain the 
development environment 

Release Management tools 8218 manages the simultaneous development of 
multiple releases 

Configuration Management tools 8210 cover the version control, migration 
control and change control of system components such as code and its associated 
documentation 

Problem Management tools 8212 pertains to the problem tracking and solution 
process 

addition, three other components are required to fully support development: 

Productivity tools 9002 provide the basic functionality required to create 
documents, spreadsheets, and simple graphics or diagrams 

Collaborative tools 9004 enable groups of people to communicate and to share 
information, helping them work together effectively, regardless of location 

Process Integration tools 9006 enforce the correct sequencing of tasks and tools 
in conformance with a pre-defined methodology 
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An efficient development environment requires good tools. For general issues 
regarding tool selection, please refer to the general Product Selection 
Considerations . 

Productivity (9002) 

While many tools are developed in order to support a specific task (for example, 
source code editor), there is a family of tools that are generally required across the 
board, often known as productivity tools or office automation tools. These tools, 
typically packaged as integrated suites of software, provide the basic functionality 
required to create documents, spreadsheets, and simple graphics or diagrams. More 
recently, the ability to access the Internet and browse electronic documentation has 
been added to the suite of productivity tools. 

Specifically, productivity tools include: 

• Spreadsheet 

• Word Processor 

• Graphics Editor 

• Personal Organizer (may be linked to Group Scheduling) 

• Methodology Browser 

• Internet Access 

These tools are generally versatile enough to take the place of specialized tools (such 
as planning tools) in certain circumstances. 
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Implementation Considerations 

a) How secure does the development environment need to be? 

In environments where security is a factor, the way in which team members gain 
access to the Internet must be carefully considered. For example, on high security 
projects, it is often the case that isolated machines with a single dial-up connection 
provide the only way to access the Internet, thus ensuring that the development 
environment remains completely isolated. 

b) Are people using the Internet for its intended use? 

Studies have shown that employees spend a lot of time using their Internet access for 
purposes unrelated to work. Therefore, the benefits and damages of providing 
Internet access must be assessed. 

Collaboration (9004) 

It is well understood that both good communication and knowledge sharing are vital 
for the success of any team. As development projects get bigger and teams more 
distributed, it becomes increasingly difficult to maintain communication between 
project team members. Collaborative tools have been developed with this very 
purpose in mind - to enable groups of people to communicate and to share 
information, helping them work together effectively, regardless of location. 

More information on collaboration may be found in the Collaboration Extensions 
Framework in the database, and the Collaboration Architecture Framework in the 
Technology Library. 
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Implementation Considerations 

a) How distributed are the project teams? 

On projects with development sites that are geographically distributed, it is usually 
the case that communication by e-mail alone is not a sufficient substitute for 
5 meetings when attempting to coordinate the teams involved. In order to keep all 
teams updated and moving in the same direction, regular (for example, weekly) 
conference calls between all parties - chaired by project management - is much more 
efficient. It is important that these conference calls are closely monitored, well 
H prepared, and that the agenda is closely followed. Action points and commitments 

j; 10 made during these calls must also be documented. Where issues arise that cannot be 
^ resolved using an audio conference (usually because the subject is based on a visual 

£3: concept), video conferencing may be necessary. 

==«, 

L E-Mail (8138) 

PLi; ' 

rO; 

rUi E-mail provides the capability of sending and receiving messages electronically. In 

y§ 15 addition to the ability to send simple ASCII text, e-mail systems usually provide the 
capability to attach binary files to messages. E-mail is a convenient tool for 
distributing information to a group of people, as it has the advantage of delivering 
content directly to the 'mailbox* of each individual, rather than relying on individuals 
to access a central data repository in order to retrieve the information. 

20 

Implementation Considerations 

b) Is e-mail likely to contain sensitive information? 



25 



When setting up an e-mail system, it is important to consider the content that will be 
transferred using the system and to apply the appropriate security controls 
accordingly. 
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• Is communication outside the local environment necessary? 

• Is remote access required? 

If so, a gateway will be required to manage communication beyond the local 
environment. This will bring with it security implications, as the local environment 
will no longer be isolated. 

c) Do e-mail capabilities already exist at the development site? 

If adequate capabilities are already present at the development site, it may well be 
prudent to take advantage of these capabilities. 

Product Considerations 

a) Is e-mail to be supported on multiple platforms? 

The choice of which product to use may depend on the platforms upon which the 
system must run. 

b) How many people should the system support? 

Low-end e-mail solutions may be perfectly adequate for small development teams. 
Teamware (8140) 

In a creative environment, it is vitally important that people are able to easily share 
ideas and information. Teamware provides the ability to capture and share 
information across a project through the use of common-access, structured 
databases. A good example of teamware is the Knowledge Xchange. 
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Teamware may be used to share many different types of information, for exampl 

• Technical support requests 

• Technical hints, which facilitate trouble-shooting 

• Change requests 

• Resource reservation (for example, meeting rooms) 

• Standards and procedures 

• Status reports/meeting minutes 

• Project member availability 

• Project events and milestones 

• Functional and technical issues 

• Suggestions 

• Project methodology 

In order to guarantee the value of a teamware environment, it is vital that: 

• Consistency is maintained 

• Relevant updates are made (including deletions) 
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• Storage is not abused 

• Security is enforced 

To ensure that information is consistent across different formats, it is useful to view 
the management of all these information sources as part of a more general 
information management process. Effective information management beyond 
repository management is required to ensure that the anticipated benefits of 
electronic mail and teamware materialize. 

For example, certain teamware databases require continuous maintenance in order to 
remain relevant. The management of the database contents may require 
significantly more work than either the initial installation of the tools or the technical 
support for the tools. This effort is frequently underestimated. 

In addition to setting guidelines for general usage, the project must designate mail 
administrators and knowledge managers who are responsible for: 

• Maintaining user accounts 

* • Maintaining security profiles 

• Managing database contents 

• Removing obsolete information 

• Managing resource usage (for example, disk space) 
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Implementation Considerations 

a) What size is the project team ? 

Teamware will generally only be effective when used within large groups of people. 
Unless a critical mass of people is achieved and content is regularly added to the 
5 system, interest will soon dwindle, and the system will no longer be of any value. 

Group Scheduling (8142) 

Group scheduling tools help to centrally manage the personal schedules of a group 
of people. This offers the advantage of being able to coordinate events that require 
the participation of a number of people automatically by checking 'group 
availability 1 rather than checking with each person individually. These tools may 
also be used to schedule other resources such as meeting rooms and equipment. 

For the use of group scheduling tools to be successful, the personal schedules of 
each member of the group must always be current. This is the responsibility not 
only of the group scheduler, but also of the individuals involved. 

15 Audio / Video Conference (8144) 

In an ideal world, all meetings would be conducted face to face. In reality, however, 
it is often the case that not all the individuals who are required to take part in a 
meeting are on the same site. To overcome this problem, audio and video 
conferencing tools allow many individuals in different locations to communicate 
20 simultaneously. Audio conferencing is not a new concept, but remains a valuable 
tool for conducting meetings where the issues being discussed do not require the 
support of visual aids. Video conferencing takes this one step further, allowing 
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people to interact both aurally and visually, making for a much richer method of 
communication. 

Implementation Considerations 

a) Is there enough bandwidth to support a video conferencing system? 

Adding bandwidth intensive applications such as audio, video, and data 
conferencing could have severe effects on the network infrastructure and this must 
be anticipated. This type of implementation is also based on a number of different, 
emerging standards. The video conferencing system should be designed with that 
fact in mind and provide for some degree of interoperability between dissimilar 
systems. For example, being able to connect a desktop-based video conference user 
with a room-based video conference user. 

b) Is video conferencing the right medium for the desired purpose? 

Video conferencing is an advantage when one person needs to see the other person's 
face, his or her reactions, read body-language, build relationships, and so on. On the 
other hand, when communication is more technical, for example, fixing a bug, 
collaborative design, document writing, or presenting a demonstration, it is more 
critical to be able to see what the other person is seeing, or to be able to show 
information at hand. In this case, application sharing assumes greater importance. It 
is a common misconception that video conferencing replaces working in the same 
place. The logistics involved in setting up a group video conference for different 
time zones, and the complexity of sharing a common whiteboard, limit the value of 
the solution to occasional situations. In a development environment, the real value 
of synchronous communication is not in being able to see someone else at the other 
end, it is in being able to share a working session on a work object. 
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Shared Workspace (8146) 

Shared workspace systems may be categorized as follows: 

• Electronic whiteboarding 

• Application sharing 
Electronic whiteboarding 

An electronic whiteboard provides a large, clear screen that can be viewed close up 
and at a wide angle, upon which participants may 'write* with an infrared pen or a 
mouse. Images may also be pasted onto the whiteboard. 

Regular workstations on a network may also be used for electronic whiteboarding, 
providing the appropriate software is installed. Electronic whiteboarding often 
works in conjunction with video conferencing applications. 

Application sharing 

Application sharing allows participants to see and control the same application 
running on multiple PCs. In this way they can simultaneously create and edit a 
single, common file. Application sharing may be combined with audio conference. 

Process Management (9006) 

Process Management may be categorized into two areas: 

• Simple process integration 8148, which concerns the simple integration of a 
sequence of tasks, according to a prescribed development methodology. 
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• Workflow management 8150, which concerns more sophisticated situations 
where several complex processes require the participation of multiple groups. 

In either situation, the aim of the process management tools is to enforce the correct 
sequencing of tasks and tools. Task integration must be provided in accordance with 
the methodology and should provide direct support for the methodology. Effective 
task integration therefore reduces the need to consult the methodology. 

Simple Process Integration (8148) 

Simple Process Integration concerns the integration of a limited sequence of tasks, 
for an individual, according to a prescribed development methodology. For 
example, the construction process can be supported within an integrated 
development environment tool by a menu with the following choices: 

• Generate module template 

• Generate windows and dialogs 

• Edit code 

• Compile 

• Link 

• Edit test plan 



• Generate testdata 
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• Execute test with debug 

• Execute test without debug 

• Edit script 

• Compare results 

The sequencing of the menu items help to remind the programmer of the steps 
needed to complete the construction of the program. 

Going beyond mere sequential use of tools, real-time integration of tools enables 
real-time data interchange. The most common example is perhaps the 
edit/compile/debug cycle. Here it can be very helpful to work in an integrated 
environment that uses the editor and places the cursor at the position corresponding 
to a syntax error or to a given break-point defined to the debugger. This integration 
is generally offered as a standard feature of an integrated development environment. 

Task integration for the individual can be achieved using scripting tools or a desk 
top manager. 

Real-time tools integration is most commonly provided by vendors who deliver 
integrated environments. 

Workflow Management (8150) 

When processes become complex and require the participation of multiple groups, 
simple integration techniques are not adequate for managing the process flow. 
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Workflow Management tools address this problem by providing the ability to define, 
manage, and execute automated business processes through an electronic 
representation of the process, both in terms of what has to be done, and by whom. 

For any process where multiple groups are involved, well-defined procedures must 
be in place to ensure that work flows from one task to another. Each participant 
must have access to the information required to perform the task, including the 
information from previous steps in the flow. This can be handled manually or 
supported by tools. If handled manually, it requires dedication, attention to detail, 
and significant training. 

Workflow Management can be applied to many processes within the development 
environment, such as quality assurance, migration, design/construction, system test, 
and standards development. 

Implementation Considerations 

Efficient tools support for Workflow Management requires standards and procedures 
that specify: 

• Which tasks exist 

• Expected and maximal duration of each task 

• What the decision points are 

• How the tasks fit together to form a workflow 

• How work is routed depending on the nature of the case/issue 
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• Which roles exist 



• Which roles can perform which tasks 



• Which individuals can fill which roles 



• Priority of cases (for example, depending on the originator) 



Product Considerations 



Workflow Management tools must at a minimum provide support for 



• Workflow definition 



• Case Routing with 



• Flexible assignment 



• Escalation 



• Exception handling 



• Reporting 



Tools to assist Workflow Management should support the following: 



• Specification of individuals, their roles and tasks, and their relationships 



• Specification of the workflow 
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• Automatic routing of cases 

• Exception handling if a task is not performed within a prescribed elapsed time 

• Routing of a case based on its contents (for example, different decision processes 
depending on the importance of the decisions) 

• Assignment of cases to roles and to individuals, with manual override 

• Assignment based on priority 

• Re-assignment of cases 

• Reporting 

Security Management (8216) 

Security Management tools provide the components that make up the security layer 
of the final system, and may provide required security controls to the development 
environment. While some of these tools may be considered as nothing more than 
security-specific Packaged Components , many are an integral part of the 
development environment toolset. 

Security Management tools include: 

• Intrusion detection - discovers and alerts administrators of intrusion attempts. 

• Network assessment - performs scheduled and selective probes of the networks 
communication services, operating systems, and routers in search of those 



- 171 - 



vulnerabilities most often used by unscrupulous individuals to probe, investigate, 
and attack your network. 

Platform security - minimizes the opportunities for intruders to compromise 
corporate systems by providing additional operating system security features. 

Web-based access control - enables organizations to control and manage user 
access to web based applications with restricted access. 

Fraud services - methods of verifying the identity of credit card users to reduce 
the amount of fraudulent credit card transactions. 

Mobile code security - protects corporate resources, computer files, confidential 
information, and corporate assets from possible mobile code attack. 

E-mail content filtering - allows organizations to define and enforce e-mail 
policies to ensure the appropriate email content. 

Application development security toolkits - allow programmers to integrate 
privacy, authentication, and additional security features into applications by 
using a cryptography engine and toolkit. 

Encryption - provides confidential communications to prevent the disclosure of 
sensitive information as it travels over the network. This capability is essential 
for conducting business over an unsecured channel such as the Internet. 

Public key infrastructure - provides public-key encryption and digital signature 
services. The purpose of a public-key infrastructure is to manage keys and 
certificates. A PKI enables the use of encryption, digital signatures, and 
authentication services across a wide variety of applications. 
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• Authentication system - provides a business with the ability to accurately know 
who they are conducting business with. 

• Firewall - protects against theft, loss, or misuse of important data on the 
corporate network, as well as protection against attempted denial of service 
attacks. Firewalls may be used at various points in the network to enforce 
different security policies. 

These tools will be discussed in detail in the Security Product Evaluation 
Framework to be published by Global TIS Security as part of the Security in 
eCommerce project. 

Product Considerations 

a) Does the tool use Role-based access control? 

Role-based access control establishes access rights and profiles based on job 
functions within the environment. If different access rights are required for security 
administrators vs. code developers vs. code reviewers vs. testers, then the correct 
access can be established based on these functions. 

b) Does the tool have flexible auditing capabilities? 

The security administrator should be able to granularly configure what is being 
audited by the tool. The audit logs should be able to optionally record User ED, time- 
of-day, location of access, successful and unsuccessful access or change attempts, 
etc. 
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c) What are the performance implications of the tool? 

Some security services, such as content scanning or auditing, may add noticeable 
processing time and requirements to the system. Tools should be architectured in 
such a way that performance impacts are or can be configured to be minimal. 

d) Does the tool comply with industry accepted standards? 

Many standards are emerging in the security technology marketplace. These include 
standards for cryptographic services, directory services, IP security, etc. In order to 
enhance future integration possibilities, choose vendors who are developing open 
solutions which comply with standards. 



Information Management (8202) 

Information Management of the development architecture is provided through an 
integrated development repository. At this level of integration, tools share a 
common repository of development objects, design documents, source code, test 
plans and data. Ideally, the repository would be a single database with an all- 
encompassing information model. Realistically, the repository must be built by 
integrating the repositories of the different development tools through interfaces. 
Tool vendors may also build part of the integrated repository by integrating specific 
products. 
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Implementation Considerations 

a) Is there a desire to enforce consistency in the development effort? 

Engagement teams should consider the use of a repository to enforce consistency 
across development efforts. A repository can store standard data, process, design, 
and development objects for use during application development activities. 
Developers then use these standard objects during implementation. As objects are 
defined once in the repository and reused throughout the implementation process, 
applications display a consistent look, feel, and flow while enforcing the standards 
inherent in the repository objects. 

b) Will analysis and design objects be reused? 

Based upon engagement experiences, an engagement team should consider using a 
repository when the development team reuses analysis and design objects and 
deliverables during later phases of the development process. A repository houses 
many application development components including data definitions, process 
models, page designs, window designs, common GUI widgets, message layouts, and 
copybooks. 

These components can be reused across large development projects to increase 
developer productivity and decrease the risks associated with coding and testing the 
same components multiple times. 

c) How large is the development team? 

Large development teams require more standardization and control in order to 
ensure that the team remains productive and maximizes reuse of analysis and design 
components. A repository provides the development teams with the ability to reuse 
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objects defined in the repository in a controlled manner. Most engagements 
consider using a repository once the number of developers exceeds ten. 

d) Is the development team geographically dispersed? 

An Information Management repository is crucial when teams whose designs must 
integrate are in different places. The repository becomes a means of communication 
that is formal and enforces the agreed interfaces. 

e) Do a number of tools need to be integrated? 

A repository management tool may be required to provide an integration platform 
for existing and future tools, providing communication among all tools where 
appropriate. 

Product Considerations 

a) Is support for user defined objects required? 

he repository may need to be extended by the Engagement team to support custom 
objects defined by the Application Development team. Some repositories support 
user-defined objects as part of the base functionality. Others allow customization of 
the repository by the user while some are not designed for customization at all. If 
the repository requires extensive customization, a buy versus build decision may be 
required. 

b) Is a logical or physical repository more beneficial? 

The Engagement team must consider the costs and benefits of a physical repository 
versus a logical repository. A physical repository is implemented as a single 
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product. Many CASE tools employ this type of repository by housing all 
application development objects in a single source. Application development tools 
are then tightly integrated with the repository. 

A logical repository integrates multiple tools to form an application development 
repository. The various tools employed in the development environment are bridged 
together by custom architecture components. This approach is commonly used 
when the Engagement team takes a best of breed approach to tool selection. 

c) What are the current and proposed future platforms? 

The Engagement team should determine whether the repository must support 
multiple platforms. The selected tool should not only support current platforms but 
also support the future platform direction of the project. 

d) Does the product support multiple versions of objects? 

The repository should support multiple versions of objects. By doing this, the 
repository can support applications in multiple phases of development. The 
repository tool should control access to the versions of objects by providing check-in 
and check-out functionality. This allows multiple developers in various phases of 
development to work from the same repository while allowing only one developer 
update access to a particular object at a time. 

e) Are there existing tools that influence the selection of the Information 
Management tool? 

Engagement teams have found that tools used in other parts of the client 
organization influence the selection of a repository tool. Clients may have 
experience and existing skills with certain Information Management tools that drive 
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the decision to use those tools corporate-wide on other initiatives. The KX may also 
provide input to the tool selection process based on previous experience and skills of 
team members. 

f) What are the other capabilities of the tool? 

Engagement teams often chose a tool that can be used in other areas of the 
development environment. Many Engagement teams select data modeling tools that 
can double as Information Management tools. Using one tool for multiple purposes 
results in fewer integration points in the architecture and less time and cost training 
personnel on multiple tools. 

g) Should the Information Management tool support multiple repositories? 

As many repositories do not provide sufficient versioning functionality, it is 
common to have more than one repository on large projects. Typically there would 
be one repository for development, one for system test, and one for production. This 
improves overall control. Another reason could be that there is concurrent 
development of different releases, each requiring its own repository. Hence, on a 
large project, a tool that supports multiple repositories is often a requirement. 

Does the Repository Management tool allow only authorized changes to be 
made to its contents by providing some form of access control? 

The repository contents are effectively the building blocks of the system and have 
broad reuse. A facility for security is required to prevent unauthorized changes to 
the repository elements and hence to ensure high quality and consistent repository 
content. For example, restrictions are often placed on making changes to data 
elements because ad-hoc changes by a single designer could have devastating 
impacts on other parts of the design. 
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Repository access control is important where developers in the development 
environment need to be assigned different rights to the repository. Typically, the 
developers will be placed in groups with diminishing access rights such as 
repository administrator, technical support, designer, or programmer. These access 
rights may relate to read/write/modify/delete authority. This method of access 
control is far more flexible than simple object locking. 

h) Does the tool provide repository reporting facilities? 

Repository reports serve as an audit trail for changes to objects within a repository 
and can be used to communicate these changes to the entire team. The Repository 
Management tool should provide this utility. 

Reports for impact analysis are extremely useful in the change control process. As 
the repository maintains relationships between repository objects, 'where-used 1 and 
'contains 1 report facilities can be very useful when dealing with change requests. 

i) Is the tool an active or passive Information Management tool? 

Active Information Management tools can be used to generate components, whereas 
passive tools are used to hold information about the tool but are not used to build the 
system. The use of an active Information Management tool increases productivity 
because of the facility to generate components. 

Does the tool need to be customized to provide an integration platform for 
all the tools in the current development environment as well as those to be 
supported in the future? 

If the repository needs to be customized in order to integrate with all the required 
tools, then it is important that the Repository tool has a published interface and 
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underlying data model. Using such a repository makes interfacing other tools with 
the repository considerably easier and less time consuming. 

Flexibility is important if a number of point tools are to be used in the 
development process as opposed to using an integrated CASE tool 

j) Does the tools repository support validation? 

All key characteristics of repository objects (for example, data elements) and their 
inter-relationships should be validated. Taking data elements as an example, these 
characteristics may include: 

• Naming standards for data element names 

• Naming standards for variable names associated with each programming 
language 

• Data element types 

• Data element length and precision 

• Data element window display and internal precision. 

At a minimum, naming standards must be validated to allow better navigation of the 
repository and easier reuse of elements. 

Does the tool provide a means of describing entities, such as source code 
files that do not exist as repository objects? 
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The integrity of references to entities that exist outside the repository but within the 
folder management system must be maintained. If the tool does not directly support 
this, procedures will have to be put in place to ensure the consistency of references 
to these entities. 

Repository Management (8102) 

Repository Management is the key information management tool. The repository 
should be: 

• Open, with a published interface and an underlying data model. In some 
development environments multiple repositories may be used. One repository 
can be integrated to an upper-case design tool, and another one to a lower-case 
design tool, each of them offering the best capabilities in their respective 
domain. It is then key that repositories offer import/export capabilities, so 
proper bridging/synchronizing capabilities can be developed. 

• Extensible, affording the flexibility for extending the type of information that 
can be captured. 

• Integrated, with the tools that are used to populate the repository and to draw 
information from the repository. 

• Scalable, the repository-enabled environment must be able to support tens to 
hundreds of users simultaneously, and tens to hundreds of thousands of 
repository relationships. It should also scale downwards, so that it can also be 
easily used by small projects. This is a major criteria for usability. 

A development repository results in three important benefits for a development 
organization and for the business units they support: 
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• Information is kept in one place, in a known and organized structure. This 
means that effort is not wasted initially in recreating work that already exists and 
effort is not wasted later on when reconciling relevant information. This is often 
referred to as "full life-cycle support." 

• Design information, created for one step of the development process, can be fed 
to the next step, reducing effort and knowledge "gaps" or misunderstandings. 

• The repository captures information relevant to each stage in application 
development: design 9102, construction 9104, testing 9106, migration, 
execution, and operation 9108. 

Figure 91 is an illustration showing information captured in the Repository and 
reused. 

The challenge is to create such a repository. Most of the available tools on the 
market do not explicitly support this comprehensive concept of a repository. 

The alternative is to: 

• Extend the repository. This is why the extensibility of the repository is so 
important. When extending the repository, consider how well future versions of 
the base repository will accommodate the extensions. Migrating to a future 
version may be more difficult after extending the repository. Extending the 
repository therefore requires a careful trade-off. 

• Use several repositories. It is not infrequent to see two repositories coexisting; 
for example, one upper-case and one lower-case repository. Bridges between 
these repositories are key. Quality of import/export capabilities of the various 
repositories are key. 
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In many instances, content may not be stored directly in the repository and must be 
placed in storage. In this case, only a reference is stored in the repository. 

When complete integration is achieved, the repository can serve as a communication 
enabler for a large collection of development tools. Figure 92 is an illustration 
showing the Repository's central role in the development environment. 

This can be achieved either by using an integrated CASE tool, or by integrating 
point tools around a common repository. 

In addition to the repository, which plays a key role, other important tool categories 
include the following. 

k) Security 

Repository access can sometimes be controlled using an access control function, 
which comes with the repository. A common technique is to group users and assign 
different access rights to the different groups. Each of these groups is also assigned 
specific read/write/delete/modify authority. For example, the following groups may 
be defined as having increasing rights: 

• Programmer 

• Designer 

• Technical support 

• - Repository administrator 
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A less flexible alternative is to lock objects. A locked object cannot be changed 
until the repository administrator unlocks it. This is a less flexible approach but may 
be used when flexible access control functionality is not part of the repository. 

A tricky, and somewhat risky, approach to compensate for lacking access control 
functionality is to use information about the repository's internal storage mechanism 
to design an access control scheme. For example, if data elements are stored in a 
particular directory, tools from the network operating system can be used to limit 
access to that directory. If data elements are stored in a particular table, tools from 
the DBMS can be used to limit rights to that table. How well this works depends on 
how gracefully the repository handles error messages from the network operating 
system or the DBMS. This approach should be tested before it is implemented. 

I) Repository Maintenance 

• Creating and Changing Data Elements - As soon as data element maintenance 
becomes structured and is based on formal requests, it is practical to make the 
requests available to the developers in electronic format. Ideally, the requests 
should be entered into a database, which also contains information on status, 
comments on the request, and other pertinent information. This database can be 
a useful communication vehicle. 

An alternative approach to maintaining history in cases where the repository 
does not offer good versioning capabilities, is to maintain a shadow repository 
where previous versions of repository objects are stored. This only works for 
those repository objects whose maintenance is strictly controlled. 
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Creating and Changing Other Repository Objects - It often occurs that the 
repository is part of an integrated CASE tool. Here, the tools used to populate 
the repository come with the repository and the integration work is already 
complete. 

This, however, is not always the case. In some instances, the tools for 
populating extensions of the repository are not provided, and in other cases, a 
stand-alone repository is used. In these cases, the integration between the design 
.tools and the repository must be performed by the Technology Infrastructure 
team. This was achieved on a number of projects that chose a "best-of-breed 
point tool" approach where they integrated these point tools around a repository. 
The integration may require some challenging work writing parsers, which 
analyze the output from the individual point tool, and use this to populate the 
repository. These technical complexities should be hidden from designers and 
programmers by providing friendly interfaces to the parsers, or by having the 
repository administrator trigger the parsing at regular intervals. 

Repository Validation and Mass Changes - All key characteristics of data 
elements, and their inter-relationships, should be validated, including: 

• Naming standards for the element name 

• Naming standards for the variable name associated with each programming 
language 

• Type (for example, numeric and alphanumeric) 

• Length and precision 

• Window display and internal precision 
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Similar validation can be performed on other repository objects depending on 
project standards. At a minimum, naming standards must be validated. This 
helps designers navigate the repository and thereby encourages reuse. 

Import and export utilities, which provide exchanges between the repository and 
flat files, can be useful in several ways. They make it easy to take a snapshot of 
the repository for archiving, and they allow for reuse of the contents of other 
repositories. 

m) Analysis, Reports, and Queries 

Reports for impact analysis are extremely useful in the change control process. As 
the repository maintains relationships between repository objects, where-used and 
contains reports are usually provided with the repository. Storing the names of 
affected repository objects in an area-affected table can be useful when grouping 
change requests during assignment, or when defining a release. The area-affected 
table is also a valuable tool that can be used to facilitate migration from 
development to system test. 

The ability to easily create various repository reports is important to leverage the 
information in the repository. A scripting language, a simple report builder, or a 
query tool provides this capability. Having a query tool with an intuitive user 
interface and good report formatting features is a necessity on a large project. The 
query tool can be used to provide standard reports for designers and programmers, 
printed design information for external reviews, and ad hoc requests for the 
repository administrator. 
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Folder Management (8104) 

It is not always practical to store all information in the same repository. One reason 
for this is the repository's physical implementation. For example, if the repository is 
implemented on top of a relational DBMS, this supporting structure does not 
provide good support for storing flat files. It may therefore often be most practical 
to populate the repository with place-holders for entities which reside outside the 
repository. With this scheme, the place-holder serves as a logical pointer. This 
scheme obviously requires some work to ensure integrity, but in practice it can work 
quite well. It works better if the objects outside can be organized in a structured 
way. This is where folders come in. They can be used to impose a structure on flat 
files; a structure, which can correspond to the structure of the repository. Folders 
should provide: 

• Flexible access rights based on user profiles, which differentiate (at least) 
between read and write access 

• Efficient search for a component across several folders 

• Migration between folders 

• Nested folders 

• Links to avoid duplication of components while still showing that a component 
belongs to several folders 

Media Content Management (8106) 

Methods for storing and managing media content range from simple folder 
management techniques to multimedia digital asset management systems, capable of 
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indexing and manipulating numerous multimedia data types. There are a number of 
key requirements for Media Content Management - in particular, a Media Content 
Management system should have the ability to: 

• Manage multiple file formats 

• Efficiently store high volume files 

• Manage metadata on files within the system 

• Manage multiple versions of media files 

• Manage revision history of changes to media files 

• Control media storage across locations (online, near line, offline) 

Whether the functionality described above is handled as an integral part of the 
system, or by manual processes implemented by the Information Management team 
depends on the richness of functionality provided by the tools chosen. 

Additional functionality provided by advanced Media Content Management tools 
may include: 

• Intelligent indexing of media types (allowing specialized search facilities) 

• Capabilities for browsing media content (low-res images, previews) 

• High performance proprietary file systems (both in terms of speed and volume) 
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Jmplementation Considerations 

a) What formats need to be supported? 

The method of Media Content Management depends heavily on what media is to be 
stored. Ensure that the target media formats are understood before implementing the 
Media Content Management approach. 

b) Where should media content be stored? 

Where to store media content greatly depends on the volume of media to be stored, 
and the performance requirements for retrieving that data. One thing is certain 
however; when dealing with large quantities of media, it is necessary to employ a 
dedicated media server, thus avoiding volume and performance hits with the rest of 
the development environment, while allowing the possibility of tuning the media 
server for optimal performance. 

The cost of data storage is not insignificant, especially when considering the total 
cost (not just that of the hardware and software, but also the effort required to 
support it). This means that much thought must be put into a media storage strategy. 
This includes a strategy for deciding which media should be on-line (instantly 
accessible), near-line (accessible with short delay, for example, CD juke box), or 
even possibly off-line (manual intervention required). 

Object Management (8108) 



Object Management tools provide capabilities for viewing objects, their methods 
and attributes, and the dependencies between these objects. 
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Object Management tools also provide specific analysis tools, in order to understand 
interdependencies between the core classes and the components. When classes and 
components are modified, impact analysis tools are required to see where the 
modified entity is being used, allowing them to understand what is the overall 
impact of the change. This is more complex than with traditional systems as a 
veritable spider's web of dependencies between classes, components, and 
applications may ensue. In addition, OO features such as inheritance and 
polymorphism make tracking down dependencies with simple text search tools 
much more difficult. 

Note: At the time of writing, none of the object management tools currently 
available on the market provide component management capabilities. 

Quality Management (8204) 

Quality Management is a management discipline that promotes a customer 
satisfaction focus and continuous improvement. Quality Management tools support 
the definition and implementation of quality. 

A number of integrated Quality Management tools are available that may combine 
the functionality of all the required quality subcomponents into a single product. 
Many quality processes however, (such as Expectation Management) do not require 
specialized tools, and are therefore supported by standard productivity tools. 

Metrics (8110) 

Metrics are an important part of quality management in that they provide a method 
of measuring (for example, sampling, testing, and determining) whether a process or 
product meets a given criterion. With Metrics, different stakeholders can agree that 
a product objectively meets an expectation, or that a process has been improved by a 
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measurable amount. Without Metrics, stakeholders can only have subjective 
opinions that may or may not agree. 

Measurement tools are used to measure process quality and product quality. Process 
quality may include Metrics such as the time it takes to process a change request. 
Product quality should be measured for all the product expectations the project has 
set. This measurement process is the inspection part of quality management. 

Statistical Process Control (8152) 

Statistical Process Control tools are used to analyze the results obtained with the 
measurement tools. These display trends that can be used as the basis for process 
improvement or, in other cases, product rework. 

Continuous Improvement (8112) 

Continuous Improvement tools are used to analyze and improve the development 
processes. 

Continuous Improvement is a process management technique by which action is 
taken to modify a process when the measurement or outcomes of that process are 
unsatisfactory. Process improvement is required whenever the number of defects 
exceeds the desired level, productivity falls below a desired threshold, or client 
expectations fail to be met. Once the process has been modified, it is remeasured to 
see whether the expected gain was actually achieved. 



Training (8154) 



Training tools provide methods to apply a standardized training approach to a large 
group of people. Training tools can complement or take the place of traditional 
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instructor-led training depending on the type of information that must be 
communicated. Computer-Based Training (CBT) tools offer the advantage of being 
able to train personnel directly on the target environment. 

At the more basic level, training tools can also include online or paper-based 
training materials - not offering all the advantages of CBTs, but still providing the 
flexibility and convenience because they can be conducted as and when the trainee 
requires, and in any location. This removes the need to organize classes. 

The decision of whether to use CBT, online, paper-based or instructor-led training is 
affected by the number of people that have to be trained, the complexity of the 
subject, and the availability and distribution of the people to be trained. 

Program & Project Management (8214) 

Program and Project Management tools assist the management teams in their daily 
work. These tools, typically packaged as integrated suites of software, provide the 
basic functionality required for planning, scheduling, tracking, and reporting at both 
the program and project level. 

Planning 

Planning tools are used to assist in program and project planning including the 
development of the Program Resource Plan, the Work Breakdown Structure (WBS), 
the Organization Breakdown Structure, Cost Accounting, milestones, and 
deliverables. 
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Scheduling 

Scheduling Tools are used to allocate resources against the WBS, to determine the 
timeline for a specific project, and to schedule the allocation of resources at the 
program level. 

Tracking 

Project tracking tools enable the project manager to track the actual project status 
against the original plan and schedule. Integration with the time reporting system 
and techniques such as Estimates to Complete (ETCs) are valuable in tracking 
project status. 

Reporting 

Reporting Tools are used to summarize status and metrics to program and project 
management. 

Configuration Management (8210) 

Configuration Management tools ensure that consistency between components and a 
given environment is maintained over time as components are changed. 

Implementation Considerations 

a) Does the testing effort involve numerous applications with common components? 

Engagement teams frequently require Configuration Management tools to support 
the testing process. Large development efforts may have multiple releases of an 
application in the development pipeline (development, unit test, integration test, user 
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acceptance test, and production). Additionally, some environments have multiple 
applications that share common components. Multiple versions of common 
components may be required depending upon the application being tested. 

Configuration Management tools assist in migrating code between these 
environments. These tools can also be used to manage different versions of test 
scripts for various releases of an application. 

b) Where is the development team located? 

Configuration Management tools are essential when development teams are not 
centralized at one location. These tools provide services, such as version control, 
when geographically distributed teams need to access common modules or data, 
such as code tables. Configuration Management tools may still be necessary even if 
the development team is centralized, depending upon other criteria such as 
development team size. 

c) How large is the application or development team? 

Large applications, as well as large development teams, require Configuration 
Management tools to help control versioning of code, changes to code, and 
migration of code (and accompanying design and test documentation) through the 
development and testing environments. 

As the size of the team increases, the communication between team members 
becomes more cumbersome. The Configuration Management tools provide a 
structure for communication between team members regarding version control, 
change control, and migration control. 
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As the size of the application increases so does the number of objects, files, or 
components. The management of these items becomes increasingly difficult to 
manage and track during the development process. The Configuration Management 
tool provides structure for managing the objects, files, and components and reduces 
the risk of lost information caused by version problems, or by items not being 
migrated properly. 

d) Is the development effort to be sustained over a prolonged period? 

Over time, a large number of configurations will evolve and Configuration 
Management tools can be used to control the evolution and to document these 
configurations. 

e) Is there a large number of components? 

It may be necessary to keep track of and control configurations consisting of objects 
such as training materials, documentation, hardware components, system software 
and even building characteristics. The existence of a large number of such 
components makes the task of managing their configurations complex, and a 
dedicated Configuration Management tool becomes crucial to the process. 

j) Are multiple organizations contributing? 

Configuration Management tools are particularly important when there are multiple 
vendors and subcontractors involved and there is a need to align what is assembled 
in preparation for the integration test. 
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g) Does the system exceed 100 modules? 

Configuration Management tools are needed once the system becomes large and 
many modules (which may include programs, header files, copybooks, shared 
components, subroutines, and so on) have to be managed. There is a significant cost 
involved in formal configuration management. If the system has a little over 100 
modules, the Configuration Management component may consist merely of a 
whiteboard or Excel spreadsheet. As the number of modules grows to about 1000, a 
dedicated tool is required. 

h) Do the generations or versions of components change frequently? 

A Configuration Management tool is important if many generations or versions are 
to be managed. This will generally be the case if the project involves a large 
development team. There may be external factors that the project team has no 
control over such as hardware vendors who change their configurations frequently. 
The internal components, for example, software modules must be configured to 
match external components such as operating systems and hardware components. 

Product Considerations 

a) Should the engagement team build a custom configuration management tool or 
purchase an existing one? 

An engagement team must determine whether to purchase a Configuration 
Management tool or build one. The build decision should consider the cost of 
designing and developing the functions required by the engagement team. 
Additionally, the project must consider the resources and development time required 
to build the tool and when the tool is needed in the application development 
schedule. 
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The buy decision can still be expensive and requires additional investments for 
training project personnel. These tools also provide many features that may not be 
required by the engagement team. 

b) Does the engagement team have more experience with certain tools? 

Engagement teams found that tools used in other parts of the client organization 
influence the selection process. Clients may have experience and existing skills with 
certain Configuration Management tools that drive the decision to use those tools on 
other initiatives corporate-wide. Andersen Consulting may also provide input to the 
tool selection process based upon previous experience and skills of team members. 
Using tools that the engagement team already has experience with provides several 
advantages, especially a reduction in training costs. 

c) Does an existing component satisfy this requirement? 

Engagement teams sometimes choose tools that provide multiple development 
functions, including Configuration Management tools. The decision to choose 
between available Configuration Management tools may already have been decided 
as a result of using certain other tools within the development environment. 

d) Does the product integrate with the existing or proposed architecture? 

The engagement team should select tools that integrate with other tools in the 
development environment and operate on the same platform. Project teams should 
select tools where vendors provide support for the integration between the 
Application Development tool and the Configuration Management tool. Such 
integration helps to easily and effectively manage the objects or files created by the 
Application Development tool. 
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How does the project define a configuration? 

Does the tool handle all types of components in the configuration? 

The components involved in Configuration Management typically involve hardware, 
system software, and application components together with their documentation. 
The tools should be able to manage and keep track of all the component types that 
make up a configuration. 

e) Does the tool provide capabilities for exception reports? 

If for some reason a repository component is not at the correct promotion level, the 
tool should be able to report on this when required. 

f) Will a source control system suffice as a Configuration Management tool? 

Generally, source control systems must be enhanced to provide a basic 
Configuration Management tool. The functional enhancements are typically: 

• Definition of a grouping mechanism for files to associate them with certain 
versions. 

• Promotion mechanisms 

• Definition of interconfiguration dependencies such as between a particular 
version's files and that version's related test data. 
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g) Does the tool provide ease of access to information? 

The tools should automate the storage and retrieval of all dependent software 
components indicated by an impact analysis report. 

Version Control (8114) 

Version Control tools control access to source code as it is developed and tested and 
allow multiple versions to be created, maintained, or retrieved. For example, a 
source code comparator can be used to identify changes between different versions 
of programs. 

The component-based development raises a new challenge: when a single 
component is used by several applications, versioning becomes significantly more 
complex and therefore, advanced versioning software, including system support for 
versioning, is required. 

Implementation Considerations 

a) Should the evolution of the system be tracked in terms of who makes changes or 
why certain decisions are made along the way? 

Version Control tools allow systematic storage of information about who makes 
changes in what order so that the evolution of the system can be tracked. 

The tools usually provide a facility to report on differences in versions so the version 
that existed when a critical change was made can be identified and recreated or 
retrieved. The tools can also provide a means of documenting why decisions are 
made during the evolution of the system. These decisions would have been made 
based on the version of the documentation for the system that existed at that time. 
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Version Control tools allow the state of the system at a particular time to be 
recorded. Hence improved auditability for decisions can be achieved. 

b) Is there a large development team? 

Version Control tools allow developers to work semi-independently and to choose 
the degree of integration they need at any given time. They can shield themselves 
from the tentative development performed on shared components and test a portion 
of the system with a stable environment around them. This prevents the 
development team from having to develop one full sequence at a time and increases 
the ability of a large number of people to work productively together, thus 
compressing the time required to develop a system. 

c) Is there concurrent development of multiple versions of the system? 

A comprehensive Version Control tool set is critical if there is concurrent 
development of multiple versions of the system. This is often the case when system 
development is to be sustained over an extended period. 

Special provisions must be made to ensure that the library and repository structures 
are rich enough to be able to support the necessary versions. In this environment, a 
log of changes also becomes very important as fixes applied to earlier versions 
generally have to be applied to later versions as well. 

d) Is it likely that the system will need to be rolled back to a previous version at 
some stage in the development? 

This is typically the case when the project is breaking ground, using new techniques 
or untried architectures. 
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Version Control tools provide a means of taking snapshots of the system in time. If 
there are changes in the environment that force the system to be rolled back to a 
previous stage in the development, Version Control tools allow access to previous 
versions and mechanisms for reverting to an earlier version. 

e) When should I set up version control? 

Version Control should be set up from the beginning. By delaying version control, 
manual Version Control must be used. This result can be an increased cost in disk 
space in the development environment (because of the number of versions of each 
module that must be kept) and can lead to some human versioning errors. 

f) What kind of information should I add to version control? 

There are different approaches: Everything (hand-made code, generated files, 
documentation, even compiled exec file or DLLs), some of the above etc. In general, 
documentation should be added if no additional design repository exists, otherwise, 
use the repository, which usually has a versioning capability. Adding binary files 
will usually have to be considered during the initial setup phase, as this requires 
significantly more memory and not all tools can handle binary files in a correct 
manner. 

g) Which stages to add? 

The stages in the version control (Dev, Assembly test, system test, etc.) should be 
added according to the development approach. Strong relationship to migration 
control. Should also be automated and is usually supported by the tools. 
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Product Considerations 

a) Does the tool provide capabilities to cater for a system running on multiple 
platforms or a distributed system? 

Ideally, the Version Control tool must be able to operate on all the platforms in use, 
whilst at the same time performing Version Control for all components across the 
entire system. 

b) Does the tool provide support for actions like mass builds? 

Usually, custom tools are put on top of the vendors tools to support actions like mass 
builds etc. Some tools (or add-ons) support this already. This is vital for the project, 
as it allows huge productivity gains in later phases of the project. 

c) How easy is it to implement batch solutions? 

It should be considered if a batch/API interface exists for implementing batch 
solutions. 

Change Control (8118) 

The Change Control system should provide the following features: 

• Free format description of changes 

• Classification of changes in several different ways (area affected, priority, 
estimated cost, authorization) 
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• Flexible, customizable sorting and reporting to ensure that a change is handled in 
a timely manner 

Ideally, the Change Control system should also be integrated with workflow 
support, the repository, and the source code control system. This ensures rapid 
processing of the change, accurate analysis of the area affected, and correct locking 
and unlocking of repository objects and source modules. 

Implementation Considerations 

a) Does the project require strict scope control? 

Specifications and scope maybe changed at anytime if Change Control tools and 
standards are not implemented. This can result in the project running over budget, 
or being delivered late with inconsistent quality because requirements change 
continuously. 

b) Is the system complex? 

Change control has broader applicability than to just application source code. It may 
also affect the look and feel, training materials, documentation, and so forth. 
Change Control must be formalized if the system is complex with many 
components. 

c) Do changes need to be authorized by specific personnel? 

Change control tools provide a vehicle for ensuring that only authorized changes are 
made and signed off. This ensures conceptual, proper ownership of the total look 
and feel of the application. Change requests may also be rejected or deferred by an 
authorized person. 
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d) Is coordination of changes required? 

Facilities to track interdependencies between change requests (for example, change 
request A must be completed before change request B can start) are provided by 
Change Control tools. This can be used to encourage efficient scheduling and to 
ensure that work is not duplicated. 

e) Should a record be kept of changes that fall beyond the capacity of the project at 
that time? 

Change Control tools can provide a vehicle for capturing good ideas. If the project 
does not have the capacity to implement those ideas at present, the Change Control 
tool can be used to capture those ideas. These ideas can be reinvestigated when a 
future release is planned. 

f) Are conflicting change requests likely to occur? 

Change request tools can be used to identify changes that conflict, for example, one 
user wants a green background and another wants a blue background. The changes 
must be resolved through some kind of dialog or discussion and Change Control can 
be used to initiate this process. 

g) Is it likely that the system will need to be rolled back to a certain state? 

This is typically the case when the project is breaking ground by using new 
techniques or untried architectures. 

Change control tools provide a means of identifying at what point in time a critical 
change was implemented and that information can be used to find out what version 
existed at that time. 
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h) Is there a need to evaluate the impact of implementing a change on the project ? 

Change control tools typically support some kind of impact analysis and may be 
integrated with an impact analysis tool set. Impact analysis is important in order to 
group changes so that they can be implemented effectively. 

Multiple changes may affect the same component and it would be wasteful to open 
that component many times over and implement the changes one at a time. Impact 
analysis can be used to ensure that all relevant changes to that component are 
implemented together. Hence impact analysis is important for scheduling purposes 
and for estimating cost. 

Product Considerations 

a) Does the tool provide a capability to classify change requests? 

Change requests may occur as a consequence of changing requirements, or as a 
result of nonconformities (or defects) in the system. The tool should be able to 
classify change requests into categories such as incidents, faults, or enhancements. 
The tool should also have the ability to update these categories if required. 

Classification of different change requests in several different ways such as area 
affected, priority, estimated cost or authorization is important to ensure correct 
scheduling of the implementation of changes. Flexible, customized sorting and 
reporting based on this classification is required to ensure that change is handled in 
timely manner. 
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b) Should an Impact Analysis tool be purchased or developed? 

Impact analysis tools are typically required to provide analysis of a wide range of 
types of documents such as Word, Excel, or PowerPoint. 

If an impact analysis tool cannot be found that supports the entire environment, it is 
critical to develop procedures or utilities that will report on where items are used. 
The first step is to identify the items to be searched, and to build procedures around 
searching them (for example, databases, files, workspaces, programs, screens/forms, 
reports). It is also important to identify who will be responsible for the impact 
analysis (DBA, analysts, programmers, team leaders, and so on) to avoid this work 
falling between the cracks. 

c) Does the tool provide free format description of changes? 

Free format descriptions are important because this allows better and more 
understandable documentation of change requests and associated decisions. 

d) Are there going to be multiple releases of the software? 

The tool should allocate change requests to different releases based on priority and 
resource availability. It should also provide a means of attaching a deadline to a 
change request. 

Does the tool provide a means of indicating which development team member is 
best suited to perform the implementation of that change request? 

This functionality should be available as part of the scheduling capability. An added 
feature would be the capability to balance workload across the team. 
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e) How does the tool handle exceptions? 

The tool should provide a capability to generate exception reports that highlight 
issues such as change requests that are in danger of not meeting the release to which 
it was allocated. 

f) What is the prediction for volume of change requests for the project? 
The tool should be able to cope with the expected volume of change. 

g) Is validation of data entered into the change request form a consideration? 

It may be necessary to ensure that the data entered on a change request form is valid. 
This is particularly important if the development team is inexperienced or if the 
project is particularly complex. An example of data validation would be to ensure 
that the change is assigned to a valid team to prevent a change request from falling 
through the cracks. 

h) Is recording of resolution details and root causes required? 

This capability provides useful tracking across the complete life cycle of a change 
request. 

i) What reporting capabilities are needed on the project? 

Some Change Control tools can report on status of change requests at the individual, 
team, and project level. Such reports can provide information about work done to 
date and Estimate to Complete (ETC) values. 



-207- 



j) How many users will simultaneously be accessing the system? 

The tool should cater to the size of the project. Maintaining consistency of 
information may otherwise become a problem with simultaneous access. The tool 
should provide some kind of protection of change requests if simultaneous access is 
likely to occur. 

k) Does the tool provide a means of prioritizing change requests? 

The tool should provide capabilities for prioritizing change requests based on 
business impact and the impact of implementing the change. 

Does the tool provide capabilities for predicting the cost, risk, and instabilities 
created as a result of implementing a change request? 

These capabilities need not provide completely automated prediction but should 
work in conjunction with an analyst. 

I) Does the tool identify component dependencies? 

This is an important aspect of impact analysis that is required to ensure that all 
components impacted by a change request are identified. 

Migration Control (8116) 

Migration Control tools control multiple versions of source code, data, and other 
items as they are changed, tested, and moved from one development environment 
into another, for example, from development to test and from test to production. 
Data migration control tools manage multiple versions of the database and its data to 
ensure that accurate data and structure are maintained in the environment, and to 
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ensure that versions of application code and database are deployed consistently. 
Types of data that would be migrated include base codes data and converted data. 

Other Migration Control tools manage other types of objects to ensure that complete 
versions of all components reside in the production environment (for example, test 
definitions and scripts). 

Implementation Considerations 

a) Are there multiple environments running in parallel? 

Multiple environments are typically required when the project is faced with serious 
time constraints. Typically the project team performs integration or systems testing 
on one portion of the system, while developing the next portion. The team corrects 
errors based on one test while at the same time, the next test cycle or testing of the 
next part of the system is performed. This means that multiple environments exist 
that are configured differently and use a different version of the system components. 
The migration of these different versions and configurations between environments 
must be carefully controlled using Migration Control tools. For successful migration 
there must be consistent migration of all components and their dependents. 

b) Are multiple releases being developed in parallel? 

If multiple releases are being developed in parallel, it is vital to provide a consistent 
means of migrating configurations and versions from one environment to the next. 
This ensures that there is no confusion of components in each release as the move is 
made from, for example, a unit test environment to a system test environment. 
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c) Is the development effort to be sustained over a prolonged period? 

Migration control tools keep a log of what is migrated. It may be required to review 
what has happened over time, in order to gain an understanding of the current status 
of the system. 

d) Is there a need to control who activates migration from one environment to the 
next? 

Migration control tools ensure that only authorized personnel can trigger the 
migration of components from one environment to the next. 

e) Is the system complex (consisting of more than 1000 components)? 

The task of promoting components and locking these components to prevent 
concurrent or unauthorized updates to them or their dependents becomes very 
intricate as the number of components reaches 1000. Migration control tools can be 
used to improve productivity by facilitating and controlling the migration from one 
environment to another and by automating the process. It is possible to bring a large 
project to a complete halt if Migration Control is not properly enforced. 

Product Considerations 

a) Does the tool support the migration of all the components that make up a 
migration object? 

The Migration Control tool should be able to manage and control the migration of 
all the components (for example, source code, database access, make files, run-time 
data, environment variables, code libraries, code tables, third-party software, and so 
forth) which make up the object to be migrated. The complexity of the Netcentric 
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world with so many integrated vendor solutions dramatically increases the number 
and variations of object types. 

b) Does the tool facilitate the migration of many components together as well as 
migrating components individually? 

Migration from a development environment to a system test environment either 
involves a large number of components (migration of all the components belonging 
to a test cycle) or single components (after code fixing in a program). Either way 
the Migration Control tool should lock the migrated component to control changes 
and allow better coordination with the system test team. 

c) Does the tool support all the required platforms? 

In a development environment where there may be different platforms, it is 
important that the Migration Control tools be able to synchronize source migration 
across platforms. Unit and system tests are normally performed on every platform 
so the migration tool should be able to promote the components across platforms as 
well as from environment to environment. 

d) What is the migration strategy? 

A push strategy should be facilitated by the migration tool if it is decided that 
modules should be tested when those modules are ready for testing. This is 
normally the case for unit testing. A pull strategy is needed if the order of 
component testing is important as is normally the case for system testing. 



In implementing a push strategy it is usual for the individual programmer to be 
responsible for migrating the module. If this is the case then the tool should be easy 



-211 - 

to learn and use. Using a pull strategy may decrease the number of people required 
to know how to use the tool. 

Release Management 

Release Management tools should provide: 

• Planning functionalities, to help planning design and development effort 

• Monitoring functionalities, in order to measure progress towards delivery goals 

• Project interdependencies management 

• Interface with the change control system 

Ideally, the Release Management system should also be integrated with workflow 
support, the repository, and the project/program management system. 

Environment Management (8206) 

The modem development environment is both complex and sophisticated. It 
supports many different functional and technical requirements (illustrated by the 
execution architecture), many different development teams, tools from many 
different product vendors, and often must support projects at different stages of the 
development life cycle. As such, it is a mission-critical production environment and 
must be managed based upon an operations architecture. The extent to which the 
areas of the operations architecture are implemented must also be a factor of project 
size and duration. 
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The environment management requirements in this section are based upon the 
MODE (Management of Distributed Environments) conceptual framework. This 
section uses MODE as a framework, adopts MODE terminology, and focuses on 
those management tasks from MODE which are particularly important in the 
development architecture. 

MODE identifies four main areas: 

• Service Management 

• Systems Management 

• Managing Change 

• Service Planning 

The subcomponents of Environment management reflect these four MODE areas. 
Service Management (8122) 

Service Management tools support the various aspects of supporting and managing 
the interface with developers. 

As defined in MODE, these include the following: 

• Tools to support and manage the Help Desk 

• Tools to support the creation, management, and reporting of Service Level 
Agreements (SLAs) and Operations Level Agreements (OLAs) 
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• Tools to manage and support the quality of the development environment 
Systems Management (8126) 

Systems Management Tools support and manage the operation of the distributed 
system. Many specific monitoring and analysis tools are covered in detail in the 
Network Performance Management practice aid and the Technology Products and 
Vendors database , both available on the Knowledge Xchange. 

Startup & Shutdown 

A comprehensive development environment rapidly becomes sufficiently complex 
that the startup and shutdown of the environment must be managed carefully, and 
preferably automated. This is key to ensuring the integrity of the environment. 
Startup may involve the carefully sequenced initialization of networking software, 
databases, web servers and more. Similarly, shutdown involves saving 
configuration changes as needed and gracefully taking down running software in the 
correct sequence. 

Backup & Restore 

The incremental value of the daily work performed on the development project is 
high. This investment must be protected from problems arising from hardware and 
software failure, and from erroneous user actions and catastrophes such as fires or 
floods. The repositories and other development information must therefore be 
backed up regularly. Backup and restore procedures and tools must be tested to 
ensure that system components can be recovered as anticipated. The large volumes 
of complex data generally require automation of backups and restores. 
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The advent of Netcentric technologies has introduced an increase in media content 
that requires storage. The environment may support a high volume of media files, 
which must be considered in the backup/restore plans. Storage capacity planning 
should allow for the typically increased size of these file types. 

5 As the amount of storage will grow significantly over time on a large project, the 
hardware requirements will increase. Sufficient room for growth should be planned 
when selecting the tools and hardware. Switching tools and hardware can be 
problematic due to lack of upward compatibility (DDS - DLT, various tools etc.). 

The time required for backups must also be considered. Usually the number of hours 
without development per day decreases over time and if backups can only be 
performed when no user is logged in, this might become a problem. It is generally 
the case that the project will benefit from buying the fastest and largest backup 
hardware/software it can afford. 

Archiving 

Archiving can be particularly useful to safeguard information from previous 
versions or releases. More generally, it is used to create a copy of information that 
is less time-critical than the current environment at a given time. Archiving may be 
performed to a medium, which is different from the backup medium, and may 
involve other tools which, for example, provide a higher compression ratio. 

20 Security 

Security tools are required in the development environment to ensure against 
unauthorized access by individuals and system processes, to limit damages caused 
by such unauthorized access, and to audit access the environment services. At the 
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security management level, it may be valuable to have tools which help manage 
security profiles, security groups, and access rights. 

Product Considerations 

a) Does the tool use Role-based access control? 

Role-based access control establishes access rights and profiles based on job 
functions within the environment. If different access rights are required for security 
administrators vs. code developers vs. code reviewers vs. testers, then the correct 
access can be established based on these functions. 

b) Does the tool have flexible auditing capabilities? 

The security administrator should be able to granularly configure what is being 
audited by the tool. The audit logs should be able to optionally record User ID, time- 
of-day, location of access, successful and unsuccessful access or change attempts, 
etc. 

c) What are the performance implications of the tool? 

Some security services, such as content scanning or auditing, may add noticeable 
processing time and requirements to the system. Tools should be architectured in 
such a way that performance impacts are or can be configured to be minimal. 

Performance Monitoring 

Performance Monitoring tools help ensure that the available resources are sufficient 
to meet the developers 1 performance requirements. These tools can be used to assess 
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end-to-end performance of both batch processes such as backups, and interactive 
processes such as repository-based file retrieval. 

Service Planning (8124) 

Service Planning is the planning required to anticipate and implement changes to the 
following areas: 

• Service management 

• Systems management 

• Managing change 

• Strategic planning 

All these areas relate to the development environment and are analogous to the kind 
of planning that must occur in the business application's production environment. 
Key types of tools for development environments include Performance Modeling 
and Capacity Planning tools. 

Performance Modeling 

Performance modeling tools in this category support the analysis of the development 
environment's performance, as opposed to that of the client/server application being 
developed. A simple spreadsheet may be suitable in some well-known and 
understood environments, but dedicated performance modeling tools should be 
considered on any project with high transaction volumes or complex environments 
involving multiple platforms. 
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Capacity Modeling 

Capacity modeling tools support the maintenance of adequate processing capacity 
for the development environment (for example, workstations, servers, storage 
devices, and network capacity). These tools range from spreadsheets to dedicated 
capacity modeling and simulation tools. 

Managing Change (8120) 

Managing Change tools support the various aspects of identifying and managing 
change in the development environment. Specific tools are discussed in detail in the 
MODE Products Database on the Knowledge Xchange. 

Data and Software Distribution is a key tool in this category for development 
environments that have several developers. These tools enable automated 
distribution of data and software to the workstations and servers in the development 
environment. 

Problem Management (8212) 

Problem Management tools help track each system investigation request - from 
detection and documentation to resolution (for example, Problem Tracking, Impact 
Analysis, Statistical Analysis). 

Problem Management tools log information about problems detected, classify them, 
and generate reports. This is essential for capturing metrics information. 

The major functions of Problem Management are: 

• Problem source and metrics information 
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• Problem solution information 

• Planning support for problem fixing and migration preparation 

• Impact analysis capability: 

• Link to the application design repository to get a precise impact analysis on a 
problem 

• Link to the test plan management system to keep track of the cycle and test 
the condition where the problem occurred, to determine the test stage work 
unit affected by the problem 

It is important to select an automated Problem Management system that is integrated 
with the program's testing and Configuration Management tools. Therefore, the 
Problem Management system must be able to support the testing model selected, for 
example, the V-modeL and have tight integration with the Migration and Version 
Control tools associated with Configuration Management. 

An automated test script tool can be integrated to allow users to reference scripts 
that were being used when the error or defect was found. A data repository can be 
integrated into the Problem Management application that will allow the users to 
build relationships between problems and design and test documentation and 
application components. 

An ability to associate problems with affected work packages and a mechanism for 
version control changes for the work package is necessary so the package can be 
migrated back into the testing environment. 
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When considering an automated tool, also consider what type of security is required 
for the Problem Management application. This is closely tied with the 
Configuration Management tools. Only one person should have the rights to review 
and approve problem analysis tasks as well as problem migration activities. 

Implementation Considerations 

a) How are problems handled at each stage? 

b) How do I plan for trapping problems? 

c) Do I retest problems at different stages? 

The following is an overview stage containment as documented by the Reinventing 
Testing Project (RTP). 

Stage containment is an approach to identify problems in the system before they 
pass to the next stage. It is a measure that helps build quality into the system. The 
goal of stage containment is to minimize the number of errors being passed to the 
next stage. For the purpose of stage containment, problems are sorted into 
categories. Errors are defined as problems found in the stage where they were 
created. Defects are problems found in a stage successive to the stage where they 
were created. Faults are problems found in production. The longer a defect remains 
undiscovered, the more difficult and expensive it will be to correct. Because each 
stage relies on the decisions made during the creation of the specification in the 
previous stage, detecting an error in a stage after it was made may invalidate some 
or all of the work done between the time the issue was created and the time it was 
discovered. 
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The V-model specifies that testing in one stage must be completed before moving on 
to the next stage of testing. Before moving up to the next stage, it is key that the exit 
criteria defined for that stage have been met. A part of the exit criteria for each 
stage is that the test has been successfully executed, therefore ensuring the test 
objectives (or primary focus of the test) are accomplished before moving on to the 
next stage. 

Once the objectives of one test stage are met, there is no need to repeat the same 
testing at the next stage. This is a key concept of the V-model and one that proves 
difficult to accept and use in practice. There is often a desire to retest just to "make 
sure everything is OK." Doing so, inevitably leads to time-consuming testing. In 
addition, it leaves less time to do the testing required for the current stage of testing, 
ultimately resulting in minimal, if any, time for the last stage of testing. In other 
words, minimize gaps and overlaps between the testing stages while ensuring quality 
of delivery. 

It is possible, however, that testing at one stage may, and should, use test scripts 
from previous stages. Two stages of testing may be executed together, using the 
same scripts, but both sets of test conditions must be covered (that is, both sets of 
objectives must be met). All stages of testing are required. For example, a thorough 
assembly test cannot make up for inadequate component testing, as the objectives of 
each test stage are different. 

d) What other components does the Problem Management system interface with? 

RTP has identified the following components as interfaces with the Problem 
Management system. 

• Configuration Management - When a defect is ready for migration, the 

Migration Control system can be used to pass the list of components to migrate. 
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The Problem Management system can keep track of the migration date obtained 
from the Migration Control system. 

• Design Repository - An impact analysis of a specific component in error will be 
performed directly on the design repository by providing a means to use the 
appropriate design repository function or having the Problem Management 
system referencing the design repository objects. 

• Test Data Management - Test results, expected results, and data comparison 
results can be linked to a defect to provide centralized access to the information. 
Integration also aids in keeping track of the cycle where the problem occurred, 
the test condition, and therefore the business function affected by the problem. 

e) How many design repositories should be used? 

f) What does the design repository interact with? 

Typically, the design repository represents the basis of the application development. 
It is mainly involved during the construction phase of the application and is used to 
centralize the application definition data. The design repository can be complex, 
providing impact analysis and application generation features. 

In a testing environment, the design repository is a safe means of analyzing the 
impact of a problem on the whole application. 

Having two separated systems, one for Problem Management and one for 
application design, duplicates the information and introduces errors. Therefore, the 
interaction between the design repository and the Problem Management, Test 
Planning, and Configuration Management components significantly increases 
productivity and reduces the risk of errors. 
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Product Considerations 

a) Are there any Problem Management tools identified? 

Problem Management tools log error information, generate error reports (such as 
System Investigation Reports or SIRs), classify problems, and record information on 
the source of the error. Problem Management tools are essential for the capture of 
stage containment metric information. 

b) What engagement factors affect the use of Problem Management tools? 

• Risk rating of the engagement - In general, management and planning tools help 
better address the engagement risks. A high risk rating for the engagement 
affects positively the decision to use tools such as Test Planning, Test Data 
Management, Problem Management, and Configuration Management. 

• Criticality of the engagement - In general, management and planning tools help 
better manage the engagement and ensure the timely delivery of a quality 
system. Therefore, dealing with a highly critical engagement will most likely 
affect positively the decision to use tools such as Test Planning, Test Data 
Management, Problem Management, and Configuration Management. 

c) What testing team factors should be considered when using a Problem 
Management tool? 

• Communication between development team and testing team - A Problem 
Management tool can be used to track issues, design changes, and so on, and 
serve as a communication tool between teams. As part of a Change Control 
mechanism for the engagement, such a tool can help improve communication 
between the development and testing teams. Thus, bad communications 
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between teams can still have a positive influence on the decision to use Problem 
Management. 

• Size of the testing team - The size of the testing team has an impact on the 

decision to use a Problem Management tool. If the testing team is large, keeping 
5 all team members informed on the status of identified problems is a more 

complex endeavor than with a small team. The larger the testing team, the more 
benefits will be derived from using a Problem Management tool to support 
testing. 

Similarly, the larger the testing team, the more benefits will be derived from 
10 using a Test Data Management tool (easier control over the test data for the 

various testers), a Configuration Management tool (easier control over all system 
configurations and component versions) and a Test Plan Management tool 
(easier control over all test cycles, subcycles, their execution statuses, and so 
on). 

1 5 System Building (821 8) 

System Building tools comprise the core of the development architecture and are 
used to design, build, and test the system. All the system building tools must be 
integrated and share development objects appropriately. 

Analysis & Design (8128) 

20 Analysis tools are used to specify the requirements for the system being developed. 
They are typically modeling and diagramming tools, which provide the ability to 
diagram system requirements and specify "what" a system must do. 
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Design tools are used to specify "how" a system will implement these system 
requirements. They are typically diagramming tools, which graphically depict how 
the system will be built in terms of its key components. This differs between 
classical client/server systems and component-based systems: 

The standard client/server model comprises application logic, presentation, and 
communication components, which together support the business processes. For a 
client/server system, each of these components must be individually defined. 

The component-based systems, however, have the data model and process models 
encapsulated within the object model. In addition, the design of the component 
model is directly affected by the business processes which govern the way these 
objects interact. Therefore, with component-based systems, the object and 
component models encapsulate the data and process models. 

Data Modeling 

Data Modeling tools provide a graphical depiction of the logical data requirements 
for the system. These tools usually support diagramming entities, relationships, and 
attributes of the business being modeled on an Entity-Relationship Diagram (ERD). 
Several techniques have evolved to support different methodologies (e.g., Chen, 
Gane & Sarson, and IDEF). 

As systems are often built on top of legacy databases, some data modeling tools 
allow generation of an object model from the legacy database data model (DDL). By 
understanding the E-R diagram represented by the database, it is easier to create an 
efficient persistence framework which isolates business components from a direct 
access to relational databases. Caution is required, however, as the resulting model is 
at best only partial, as an object model has dynamic aspects to it as well as static 
relationships, and may not correctly reflect the analysis performed in the problem 
domain. 
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When a component or object-based approach is used, data modeling is not 
performed. Rather, the object model contains both the data and the behavior 
associated with an object. In most systems relational databases are used and the 
object model must be mapped to the data model. Standard mechanisms for mapping 
5 objects exist. Tools such as Persistence (Persistence Corp.) and DBTools (Rogue 
Wave) can generate the code necessary to map objects to a database. 

Implementation Considerations 

a) Can the development process benefit from a DDL generation tool? 

Data modeling tools allow DDL to be generated from the data model. The tools 
should support DDL generation for the chosen RDBMs (Sybase, Oracle, DB2). In 
addition, the DDL generator should take advantage of the specific advanced features 
supported by each of the RDBMs. 

b) Can developers benefit by a graphical depiction of the logical and physical data 
requirements? 

Data modeling tools help to graphically develop the logical and physical data 
requirements for an application. These tools depict logical constructs such as 
entities, attributes, and relationships between entities, along with physical constructs 
such as database definitions and table indices. 

It is useful for developers to have read-only access to either a hard or soft copy of 
20 the data model during development. This document rapidly becomes a key 

discussion document in design discussions. It is useful to show tables, columns, 
primary keys, and foreign keys (if all of this will fit on a diagram at the same time !) 
in the document 
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Graphical depiction is not only useful but essential to data architects, DBAs and also 
to application developers (the latter group is often omitted). As in most cases, a 
picture speaks a thousand words. 

c) Is there a need for consistency in data across applications? 

Data modeling tools promote consistency in application development by defining 
standard names and attribute characteristics for the application data. Application 
developers then use the standard entity and attribute definitions across various 
application development initiatives. This results in a consistent definition and usage 
of data. For example, all applications that require customer number will use the 
standard name and attribute length defined in the data model. Database 
administrators will also use the data model to generate physical database definitions 
that are consistent with the application under development. Thus, the data model 
acts as a single source for data definition. 

All applications should have data consistency that is linked back to a set of business 
data standards. Failure to achieve an agreed set of definitions will jeopardize the 
ability of the separate applications to perform as a business unit, for example, 
applications will not be able to share data if they are in different formats or use 
different code lookups. Data consistency must be agreed FUNCTIONALLY during 
analysis and design. Data modeling tools will help to document data definitions but 
they will not automatically enforce data consistency. 

d) Are there more than 100 entities in the data model? 

At this level of complexity a dedicated data modeling tool is necessary. 
Does the system incorporate object oriented methods? 
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Is a relational database being used to store persistent objects? 

Fully normalized data models are a different view of the corresponding object 
models. On the one hand, the data model does not show behaviors (methods). On 
the other hand it does show resolving entities that are normally modeled as container 
5 objects and may be internal to an object. A data modeling tool is useful for showing 
how the persistent objects map to the relational database. 

e) Is there a need to communicate the business data requirements without regard to 
the DBMS or platform ? 

A data model is a technology-independent model of an organization's data 
10 requirements consisting of diagrams and descriptions of entity types, attribute types, 
relationship types, and integrity constraints. It is a flexible, non-redundant, non- 
constraining model. As a simplified representation of reality, it has no regard for 
such physical matters as how data is to be retrieved or how long it will take. The 
data model presents a concept of the business data in an idealized structure. It is a 
15 useful tool to communicate the scope of the project. 

f) Is the system complex and changing? 

Good data modeling requires a full understanding of the business data involved. 
Data modeling becomes more important as systems become more complex and 
sophisticated. The data structures which support such systems must be flexible and 
20 be able to accommodate change. The data model is the best means of identifying 
and representing these changes. 
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g) Is database design going to be performed? 

The finalized data model is used as a basis for the logical database design. The 
logical database design converts the finalized Project Data Model to one of four 
basic structures, according to which DBMS is used: 

• Hierarchical (rarely used today) 

• Network (e.g., IDMS) 

• Relational (e.g., DB2) 

• Inverted List (e.g., AD ABAS) 

Although entity-relationship diagrams are independent of specific DBMSs or access 
methods, a logical database design is not. This design is highly dependent on the 
platform components and may need to be repeated for each location type and 
platform type. This process is simplified if a data model is used. 

h) Does the system interface with external systems having their own data 
definitions? 

Data modeling tools allow documentation of the data in so far as it appears in the 
data model (and ultimately in the database). However, there is usually a significant 
number of other data definitions which will never appear in the database, and whose 
definition is different to the data model attributes. For example, most systems have 
interfaces to external systems, and inherit a legacy of interface files whose data 
definitions may differ to those on the data model, but which do logically correspond 
to fields on the model. These data definitions must also be documented and stored 
but are effectively outside the data model. The data modeling component should be 
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used to implement procedures to address all the data definitions that affect the 
system. 

Product Considerations 

a) What is the intended use of the tool? 

The features required in the data modeling tool will depend on the intended use of 
the tool. If the tool is to be used to develop logical data models, it should support 
logical constructs such as entity definition, attribute definition, subtyping, and 
supertyping. If the tool is to be used for physical data design, it should support the 
physical constructs required for the targeted RDBMs, such as transforming a logical 
model into a physical model, database definition, index definition, and DDL 
generation. 

b) Does an existing component satisfy this requirement? 

The development architecture may already have tools that support data modeling. 
For example, many information management tools (repository) provide data 
modeling capabilities. Using a single tool for multiple functions reduces the 
developer learning curve and provides integration between the components of the 
development architecture. 

c) What other utilities are available with the data modeling tool? 

It is important to consider the various utilities available with the data modeling tools. 
Two such utilities include impact analysis and reporting. 
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Impact analysis capabilities allow the user to understand the impact of a change to 
the data model. Impact analysis functionality is one of the key tools used by 
engagement teams to assist with change management and change control activities. 

Some products will also include report generators which are useful for generating 
data and attribute definition reports as well as ad hoc reports. 

d) Does the development team have any prior experience with data modeling tools} 

A data modeling tool may be chosen based upon prior experience with the tool by 
the client or members of the engagement team. This reduces the learning curve 
associated with integrating a new tool into the development environment. 

e) How well does the data modeling tool integrate with other development tools? 

Data modeling tools commonly integrate with the repository and with system 
building tools such as window painters and Application Logic Design tools. If the 
tool does not provide seamless integration with other components of the 
development environment, the engagement team can build bridges between 
components, or develop manual procedures in order to share information. 

It is important to consider how the data modeling tool integrates with the design 
repository. It is important to maintain a cross-reference of the attributes on the 
model, with the definition of data elements in the design repository. Such data 
element definitions will also address non-database data definitions (e.g. external 
i/face files). 
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f) What level of data modeling is required? 

During the early conceptual design, data modeling need not be very detailed. It 
should be a participative, team activity, and is usually very unstable. In this case, a 
tool such as a white board or PowerPoint will suffice. 

As the design becomes more detailed, more sophisticated tools are needed. At the 
lowest level of detail consistency is vital and a repository-based tool can be used to 
ensure consistency across the data model. 

g) Should the data modeling tool provide database design facilities? 

There are some tools which do not incorporate this feature, such as ARIS, which is 
strictly a data modeling tool. This may be helpful to guard against moving too far 
into the design during the analysis phase. 

Most data modeling tools allow you to develop the database design at the same time. 
This has the advantage of keeping costs down as two separate tools need not be 
purchased, and of ensuring consistency by providing a direct interface between the 
two phases. 

h) Does the data modeling tool support submodeling? 

Submodeling enables complex models to be broken down into smaller more 
manageable and understandable models while still maintaining unique object 
definition. This is particularly important for large teams where data modeling is 
divided among several teams. 
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i) Does the data modeling tool provide support for a multi-designer environment? 

The information management component may provide the security needed in a 
multi-designer environment. If this is not the case then a multi-designer data 
modeling tool should be used. The tool may provide a central dictionary which 
allows design data to be shared between several designers and includes security 
checks to monitor any conflicts in overlapping access rights between designers. 

j) Does the tool provide facilities to add color to the data model? 

The facility to add color to the data model is useful for communicating additional 
dimensions such as data ownership. 

k) Is entity life history required to be documented? 

The data modeling tools must support a facility for ELH modeling for entities that 
have their status changed by a wide range of events. Any entity which has an 
attribute containing the word status is a likely candidate. 

I) At what point should inconsistencies in the design be controlled? 

Designs should be consistent. However, enforcing internal consistency at all times 
can lead to design gridlock which prevents innovation or progress. The tool should 
support the project decisions regarding consistency. 

Process Modeling 

Process modeling tools provide a graphical depiction of the business functions and 
processes being supported by a system. The tool(s) selected must support the 
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modeling techniques being used in the development methodology. These include 
process decomposition, data flow, and process dependency. 

Implementation Considerations 

a) Are the processes that the system is to support ill-understood or is there little 
consensus on what these processes are? 

Process modeling is a method for clarifying and communicating the business design 
of the system. The process model can provide an effective means of bringing people 
together, creating a shared vision of how the business is to function. 

b) Do the processes vary from region to region and need to be standardized? 

A process model provides a means of standardizing a set of similar processes which 
exist, for example, at different branches of the business. 

c) Does the project include process re-engineering or process-streamlining? 

The re-engineered processes in the process model may form a basis for the systems 
design which is to come afterwards. Requirements and constraints for the system 
design can be well represented and communicated in a process model. 

d) Is process simulation required? 

Advanced process modeling tools provide process simulation capabilities. Process 
simulation ensures that the process design is adequate as a basis of the functionality 
of the software that is to be developed. 
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Product Considerations 

a) What approach is to be used for process modeling? 

The tool may need to support the creation of business function decompositions or 
data flow diagrams depending on the approach used. 

Data flow diagramming is used when the application has a complex or innovative 
workflow or if the analysis and design teams have little experience with the 
application. 

Business function decomposition is used when the application is fairly routine and 
the team has extensive experience with similar applications. 

b) Does another component support procedure diagramming? 

A business function decomposition diagram can be produced using a procedure 
diagramer. 

c) Are common process symbols to be reused? 

The tool should provide a facility to create custom symbols for the process flow and 
these should be reusable. 

d) Does the tool support the expected size of the process model? 

The process model may include hundreds or even thousands of processes. The tool 
should be able to support the expected size of the process model. 
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e) Does the data flow diagramer support leveling of diagrams? 

Some tools allow leveling of the diagram in which a process box on a high level 
diagram is decomposed into multiple processes on a lower-level diagram. To ensure 
that the diagrams are easy to understand and that they easily convey information, it 
is useful to keep the diagram size to one window or one printed page. The facility to 
level a large diagram can help to achieve this. 

f) How does the data flow diagramer support data stores that are used by more than 
one process? 

It is often the case that processes that share a data store cannot be placed near each 
other on the diagram. To avoid complicating the diagram, some tools allow data 
stores to be depicted more than once on the diagram. The tools may provide 
facilities to differentiate these stores from stores that have not been duplicated in this 
manner. 

g) Can control flows be represented by the data flow diagramer? 

It may be necessary to depict control flows. The tool may represent these as data 
flows without any data elements, such as, for example, a signal from a timer 
function. 

h) Does the tool support validation of the diagram? 

To ensure that a data flow diagram is complete, each process should have at least 
one input and one output. Unless data stores are shared with other systems, each 
attribute of each data store must have at least one input flow associated with it. The 
tool should facilitate the identification of exceptions to these general rules. 
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i) Is a detailed process model with complex processes to be documented? 

At the lowest level of a data flow diagram or a business function decomposition, 
there may be processes that are still too complex to be explained by a label or even a 
short paragraph. For example, this may be the case if complex interest rate 
calculations are to be performed by the process. An elementary process description 
may be required for each such process. The process modeling component should 
include tools that enable the description to be documented. The description may be 
formatted as plain English, structured English (resembling pseudo-code), decision 
tables, or as action diagrams. 

Event Modeling 

Event modeling tools provide graphical depiction of the events and associated 
responses for the system. A variety of tools and techniques can be used for event 
modeling, for example, word processors to develop simple textual lists of events and 
data flow diagramming to show events and responses. 

For component-based development, event modeling or interaction sequence 
modeling may be performed through interaction diagrams, both at the object and 
component level. The event model is often used as input for test scripting. 

Implementation Considerations 

a) Is there a need to capture the essence of how the business functions without 
becoming tangled in the current sequence of processes? 

Event modeling does not fix the sequence of processes. A process starts when a 
specified event occurs, and may generate other events when it has finished. Event 
modeling notation allows focus on what steps the process must do as opposed to 
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"how" it sequences the steps. This form of representation is especially useful for 
processes that will be re-engineered, since it allows steps to be re-arranged easily. 

b) Is there some uncertainty about the functional requirements or scope of the 
system? 

An event model represents external actions which the system must recognize and 
responses which the system must produce. Events express the system's perception 
of external activities. Therefore, event modeling allows the external environment to 
influence the requirements definition, rather than basing the environment on the 
applications structure. This approach supports the applications consistency with the 
workflow and other business activities and thus clearly defines the scope of the 
system. 

c) Are the business requirements of the system to be communicated to a large team 
or to the users? 

An event model represents the user requirements in concise business terms. When 
used in conjunction with the process model, this provides an effective means of 
communicating the system requirements from the business design team to the 
systems design team or to the users. 

d) Does the architecture have several disjoint systems that need to respond to the 
same business event? 

By using event modeling and a central event router architecture, interfaces to several 
systems can be easily and flexibly provided. Each system registers itself with the 
event router and indicates which business events it is interested in. Whenever an 
event is triggered, the router is notified. It then triggers all the applications that 
registered themselves as being interested in that event. 
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Applications can generate events as required to ensure that appropriate next steps in 
the process are performed after they have completed their part. 

e) Is a real-time system to be developed? 

Real-time systems require very strict responses to events within specified time 
frames. Event modeling is critical to ensure that real-time systems meet this 
requirement. 

f) Is the extent of change to the business particularly large such that a detailed 
requirements model is needed? 

The requirements model (event, process, and data models) provides a clear means of 
depicting the system. The requirements model summarizes the relationship between 
events, data, and processes. It consists of the event model, the process model, and 
the data model. The event model is important because it details the business 
transactions and events enough to understand the process and data models. Event 
modeling tools must be provided to complete the requirements model. 

Product Considerations 

a) Do other tools provide the required functionality? 

Event modeling and process modeling go hand in hand and are typically provided by 
the same tool. 

b) Are events triggered by time easy to represent? 

The modeling tools chosen should provide a means of clearly depicting events that 
are triggered by time e.g. the year end event. 
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c) Does an existing component provide all the necessary facilities? 

A flow charter is generally required to graphically depict the events. There is also a 
text description of the events which can be documented using a tool such as MS 
Word or MS PowerPoint. Entity life cycle diagrams, Event-Stimulus-Response 
diagrams or matrices, or Context diagrams may be required to complete the model. 

d) Is the system complex? 

As the number of events increases, the complexity of the event model increases and 
the diagramers may need to support certain facilities such as intelligent connectors. 
Simple graphics packages may not suffice at this level. 

Performance Modeling 

The performance of a system must be analyzed as early as possible in the 
development process. Performance modeling tools support the analysis of 
performance over the network. A simple spreadsheet may be suitable in some well- 
known and understood environments, but dedicated performance modeling tools 
should be considered on any project with high transaction volumes or complex 
distributed architectures involving several platforms. 

In the case of Internet-based applications, as the Internet is not a controlled 
environment, performance modeling is limited to those components within the 
domain of the controlled environment (i.e. up to the Internet Service Provider). 
However, In the case of intranet-based systems, where the environment is controlled 
from end-to-end, performance modeling may be performed across the entire system. 

Performance modeling for components involves the analysis of the projected level of 
interaction between components and the level of network traffic generated by this 
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interaction. It is important for performance reasons that communication between 
components is minimized, especially if these components are distributed. 

Implementation Considerations 

a) Is the system complex or heterogeneous? 

A performance model ensures that performance requirements are met in a complex 
or heterogeneous environment. Performance is usually a critical quality requirement 
in such environments. 

b) Does the system involve extensive communication over a Wide Area Network? 

The complexity involved in designing systems over a WAN makes performance 
modeling tools critical to success for such systems. 

c) Are there hundreds of users? Are there tens of servers? 

Due to the complexity of such systems, performance modeling tools are important in 
ensuring performance requirements are met. 

d) Do experience and benchmarks indicate that there may be difficulties in meeting 
the performance requirements as stated for the system? 

In this case performance modeling tools are critical, since penalties may be incurred 
if the system does not meet the performance requirements. A performance model 
provides a means of deciding early on whether the system is feasible or not. 
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e) Is what if analysis required for future growth? 

f) Is what if analysis required for alternative hardware configurations? 

g) Is what if analysis required for hardware loading? 

Performance modeling tools provide a means of analyzing how much future growth 
or what alternative hardware configurations can be sustained before the system 
breaks down. This component may be needed even though it is obvious that the 
system will meet the current performance requirements. 

h) Are high transaction volumes or complex architectures expected for the system? 

Dedicated performance modeling tools should be considered for any project that 
involves high transaction volumes or a complex architecture with several platforms. 
Performance is critical for such systems and a performance model is required in 
order to predict and optimize that performance. 

Product Considerations 

a) Does a generic tool such as a spreadsheet package suffice as a performance 
modeling tool? 

A specialized performance modeling tool should be used when the system is 
complex and involves high volumes of data, or is heterogeneous. 

As design progresses from high level conceptual design to detailed design, to 
technical design, there is a corresponding sequence of activities involved in 
performance modeling. As the design becomes more detailed, so does the 
performance model. The model may start as a simple spreadsheet and evolve into a 
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collection of spreadsheets with many sheets in each book. As the structure and 
parameters become overwhelmingly complex, a dedicated modeling tool with its 
own data model, user interface etc. is a good investment. 

A performance modeling tool should not be purchased due to a lack of 
understanding or inexperience of performance modeling, since the tool will not 
clarify the issues any more than a spreadsheet model. 

b) Does the tool allow empirical data to be fed back into the performance model? 

Performance modeling must be backed up with empirical data at the earliest possible 
stage. Initially, this will be through performance benchmarking usually using a 
small equivalent of the production system. The results should be fed back into the 
performance models to improve their accuracy. There should be a means of 
differentiating empirical data from estimates in the model. 

Object Modeling 

An object model usually contains the following deliverables: 

• Class Diagram (1 per functional area or 1 per component) 

• Class Definition (1 per class) 

• Class Interaction or Sequence Diagram (1 or more per scenario / workflow) 

• Class State Transition Diagram (1 per Class with complex state) 
Guidelines for creating object models can be found in the ODM MKB database . 
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Tools such as MS Word, MS PowerPoint, ABC Flowchart (Micrografix), may be 
used to produce these deliverables. Specific modeling tools do exist, however, and 
provide advantages such as cross referencing (for example, are all the methods used 
in the Interaction diagrams described in the class definitions?), automatic 
propagation of changes to other diagrams, generation of reports, and generation of 
skeleton code. However, some tools have problems with: 

• Usability and stability 

• Single users or small numbers of concurrent users 

• Proprietary repositories (usually file-based, rather than DB-based) 

• Support of extensions / customization 

As well as providing the usual editing and graphical functionalities, a good modeling 
tool should: 

• Interface with a repository (to support versioning) 

• Support multiple users 

• Generate code from the design 

The use of UML notation to represent the object model is becoming more and more 
common. In this case other diagrams such as Use Cases (from Ivar Jacobson) and 
Collaborations Diagrams complement the model. 
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Component Modeling 

Component modeling can mean either designing components from scratch, or 
customizing and integrating packaged software. No specific component modeling 
tools exist, and current object modeling tools only offer limited support for 
components (e.g. for packaging related classes together). Class packages can be 
used to separate the object models for different components, with a separate class 
package(s) for the component model. This approach, however, is not enforced by 
current modeling tools, and requires project naming and structuring standards. 

When component modeling is being performed using existing packaged software, 
some form of reverse engineering or importing is required from the modeling tool to 
capture the existing design. 

During component design the partitioned component model is designed, which 
defines physical interfaces and locations for components. It is important for 
performance reasons that communication between components is minimized, 
especially if they are distributed. 

Reuse Support 

It is during analysis and design that really large savings can be obtained by reusing 
existing solutions. At this stage, reuse is often at the subsystem level but can extend 
down to the service and module level. Asset navigation tools, which permit the 
retrieval of reusable components, can therefore be of great value. 

For a component-based or object-based solution, reuse is usually with a specific aim. 
It occurs at different levels and requires different types of support. 



-245 - 

At the analysis and design stage, common classes and components are used across 
applications. Repository management is required that allows easy browsing and 
sharing of pieces of design. 

During the construction phase, there may be strong interdependencies between the 
5 core classes and the components. This must be taken into account when planning 
the work. When classes and components are being fixed or modified, impact 
analysis tools are needed to see where the modified entity is being used. This is 
more complex than traditional systems as a veritable spider's web of dependencies 
between classes, components, and applications may ensue. In addition, OO features 

O 10 such as inheritance and polymorphism make tracking down dependencies with 

jj simple text search tools much more difficult. 

™; In terms of tools, a class or library browser is required, which allows easy 

M» navigation and identification of candidate components and classes. 

^rj; In many cases, there can be a mismatch between design and build, especially if no 

rU? 15 detailed design phase exists. This may result in the existence of two repositories. 
y3 : The object or component model produced in the design phase is at a higher level and 

gives a good introduction or overview. The actual code, however, is where 
developers tend to go to find out how an application really works. When this is the 
case, the source code can be used as the detailed design. There are tools that extract 
20 documentation (from comments in a given format) and generate HTML pages. 
Examples of such tools include: 

• Java - javadoc, part of the jdk 



C++ - available from http://www-users.cs.umn.edu/— kotula/cocoon/cocoon.htm 
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The ideal situation is a single repository for analysis, design, and code, allowing 
developers to move from design to code and vice versa. However, most tools have 
proprietary repositories and their import/export facilities are not sophisticated 
enough to merge the two. For the moment, source code and design documentation 
remain two separate repositories. 

Prototyping 

It is frequently difficult to obtain specific, reliable, and complete requirements that 
truly express what users need. This may stem from users being unavailable or 
inexperienced with computer systems, or it may arise from the nature of the system 
under design. For example, if the system incorporates very new technology, it may 
be difficult for users to visualize the possibilities. 

Prototyping can address this problem by simulating key user interface components, 
thus enabling the development team to measure the usability of the proposed system 
at a very early stage. The most important quality of a prototyping tool is its 
development speed. If prototyping can be performed in hours or days rather than 
weeks or months, it becomes possible to perform more iterations, which explore 
different options. This may lead to a much better system, given that the user's 
perception matures with each iteration. This, in turn, improves the quality of user 
input. 

Very rapid, lo-fidelity prototypes (for example, paper-based) play an important role 
in early prototyping. Hi-fidelity prototypes, used later on in the design process, 
should be as close to the target system as possible, and highly detailed - even down 
to the characteristics of a button click (e.g. click-down image, click sound, length of 
click etc.). This way, everyone (including the design teams) can determine exactly 
what the final system should look like. 
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User involvement at the prototype stage is of the utmost importance - regular user 
reviews as the prototype evolves will ensure buy-in from the users, and avoid 
unpleasant surprises at later stages of development. 

Caution must be taken not to raise the expectations of the users in terms of the 
length of time it will take for the final product to be delivered. Prototyping will 
deliver something that looks like it "works" very quickly. It should be clear that 
what is delivered is a model and not an application. Clients may expect real 
application functionality to be developed and delivered quickly due the fast 
turnaround of the prototyping process, which will invariably not be the case. 

Prototypes may also be used to prove architecture concepts (for example, to verify 
the flow of messages from the client to the host), to ensure that the system is not 
based on an architecture that is fundamentally flawed. 

It is important to determine whether to carry forward and extend the prototype, or 
throw it away after requirements have been determined and perform technical design 
from scratch. Some prototyping tools offer the possibility of reusing code from the 
prototype. Although this is a valuable option, it is often available at the cost of 
slower prototype development. An interesting compromise may be to keep portions 
of the prototype (for example, user interface components) and rebuild other 
components from scratch. 

In component based development, prototyping may be a valuable way of checking 
that component boundaries are well defined. However, this implies that the 
architecture must be defined at the time of prototyping. 

Specific multi-platform prototyping facilities may be required when developing and 
deploying applications across multiple platforms. 
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Prototyping functionality is usually included in Integrated Development 
Environments (DDE). 

WARNING: If the prototyping tool used is not part of the execution environment, 
the use of features that are difficult to implement in the target environment should be 
avoided. Prototypes will set user expectations, which may be difficult to meet once 
construction starts. Specifically, it is important to ensure that the performance of the 
prototype does not exceed the projected performance of the target system. If user 
expectations are built upon a highly-performant prototype, there is the potential of 
considerable disappointment when the final system is rolled out. 

Implementation Considerations 

a) Will the target system run on multiple platforms? 

If so, it may be important to ensure that the prototype also runs on multiple 
platforms (particularly if the prototype is a technical prototype as well as a 
functional one). 

b) Is application performance an important consideration? 

Prototyping tools can be used to identify potential performance problems in an 
application. A development team can use a prototyping tool to implement a portion 
of an application to identify performance problems. The team can then use this 
information to improve designs and provide guidelines and standards for designs. 
Thus, prototyping leads to a better designed and more consistent end product. 
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c) Do the users have experience with GUIs? 

Prototyping tools allow engagement teams to demonstrate the look and feel of an 
application to the end user. The tool should be capable of providing a realistic 
understanding of the final application without requiring an extensive construction 
effort. 

Prototypes can be used to interactively gather business requirements and design the 
application with the end user. If the tool supports interactive prototyping, changes 
can be quickly incorporated into the prototype and demonstrated back to the user. 
This is important when users are inexperienced with GUI. Prototyping the look and 
feel of the application and interactively gathering business requirements assist in 
gaining user acceptance of the system. 

d) Are the system requirements ill defined, vague and poorly understood? 

A prototype provides a means of communicating what the system is intended to do 
and can clarify system requirements. The prototype may become a throw-away if it 
becomes clear that the development style of the prototype is not conducive to a 
quality product. It is often more cost effective to start afresh incorporating the added 
understanding which was developed during the prototyping stage. 

e) Are the user requirements vague? 

It is frequently difficult to obtain specific, reliable, and complete requirements that 
truly express what users need. Prototyping can solve this problem by simulating key 
user interfacing components. User interface issues which are detected later are 
generally costly to change. 
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f) Is this a high usage and dedicated system, where throughput matters? 

If the system is to be used by dedicated people where the measure of productivity is 
solely the number of transactions they can get through per second, then user 
interface prototyping tools are important. Prototyping tools provide a means of 
getting to the easiest and most efficient interface. Prototyping tools facilitate 
selection between alternative styles of interaction and provide a means of addressing 
performance issues. 

g) Do the users have a choice of whether or not to use the system ? 

User interface prototyping tools are important since they allow developers to obtain 
user input early on in the GUI design process. This induces user ownership and 
acceptance of the system. 

h) Is user input a criterion for getting the system adopted, such as might be the case 
when a union or organized labor is involved? 

By using prototyping tools to get user input, ownership and acceptance of the system 
is facilitated. Adoption of the system by users and ensuring that their expectations 
are reasonable can make the system less expensive to deploy. 

i) Does the technical architectural design use new or unfamiliar components or does 
it use a proven system? 

Prototyping the technical architecture provides an ideal way to quickly determine if 
the design is feasible before a major commitment is made to a design that cannot 
work. 
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j) Are selected parts of the system to be piloted on the project? 

Portions of the application could be selected for design and coding in advance of the 
full-scale design/code effort. This will help iron out architecture issues, user design 
preferences, standards, designer/development training requirements, and produce 
quick wins for the project which can build morale for the team and client. A 
prototype can serve as a means of identifying the portions to be piloted. 

k) Are new team members likely to join throughout the project? 

A prototype can serve to quickly familiarize new team members with the user 
requirements, reducing the ramp-up time for new team members. Project team 
members should be familiar with the goals and use of a system in order to 
effectively develop an application. 

I) Is the project management team unfamiliar with the development team they will be 
working with? 

Prototyping allows the project management team to judge the capabilities of a 
development team with whom they are unfamiliar. The prototyping effort allows 
some preliminary assessment of skill sets. 

m) Is there some uncertainty about the product to be used in construction? 

Prototyping can allow the project team to validate the capabilities and characteristics 
of products which will later be used for development. Many products 
(PowerBuilder, Visual Basic, etc.) are marketed as being the best, but may fall short 
of project requirements. Use of such tools during prototyping allows some 
"qualification" of a product's true capabilities. Performance, compatibility with 
existing client infrastructure, etc., can be tested. 
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Use of a product during prototyping (that is early purchasing) also allows a 
development team to determine the quality of the technical support within the 
company providing the product. It also allows time to work through some of the 
business models of those companies (their willingness to negotiate on issues, 
5 pricing, etc.). 

n) Is system performance an important factor? 

Prototyping and benchmarking the performance of a technical environment enables 
possible performance problems to be identified as early on as possible. 

o) Do the users have little or no experience with the interface technology? 

Prototyping serves as a means of introducing the users to the interface. Problems the 
users may have in working with the interface can be identified early on, and can be 
accounted for in training materials that are developed. 

p) Is there a high degree of innovation in the work flow? 

Prototyping allows the developers to experiment and, with input from users, come 
15 up with the best solution to a new and unproven workflow. 

q) Do the project team and client fully understand the review and sign-off process? 

Prototyping allows the project team and the client to work through the issues and 
mechanics of the review and sign-off process prior to the intensive development 
phase. 
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Product Considerations 

a) What is the purpose of the prototype deliverable? 

b) Is the deliverable used to document the design of the application or provide an 
accurate depiction of the look and feel of the application? 

An engagement team should select a prototyping tool to support the level of detail 
for the prototype deliverable. Initial application prototypes may use low-fidelity 
prototyping techniques (prototypes built using MS PowerPoint or pencil and paper, 
etc.) in order to document initial window designs and determine dialog flow 
(navigation). Some advantages of low-fidelity prototyping include little or no 
learning curve, lack of standardization which increases designer creativity, and ease 
of modification. However, this type of prototyping can not provide the user with 
the look and feel of the final application. High fidelity prototypes require more 
sophisticated tools which can provide a more realistic depiction of the application. 

c) Is the prototype demonstrating the application behavior to the users? 

d) Is the depiction of application behavior used in development decisions? 



A prototyping tool should deliver an accurate depiction of the application including 
window flow and business functions. The prototyping tool should allow the display 
of datia in a window with the look and feel of the navigation. 
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e) Is reusability of prototype deliverables a requirement? 

f) What is the objective of the prototype? 

Depending on the objectives and timing of the prototype, all or part of the prototype 
deliverable can be reusable during later stages of the application development 
5 process. Some projects create prototypes in the very early stages of design to 
demonstrate the capability of the tool and obtain user acceptance, rather than 
gathering business requirements and documenting design based on the requirements. 

If the objective of the prototype is to document designs based upon business 
requirements, then prototyping tools should be chosen with reuse in mind. 

10 g) Is the prototype used to gather business requirements? 

h) Is the prototype developed during Joint Application Design (JAD) sessions with 
users? 

The prototyping tool should be easy to use so the application designer can quickly 
incorporate changes to the prototype. User input should be incorporated as quickly 
15 as possible into the prototype and demonstrated back to the user. This helps to 
acquire user sign off on the application design and to gain acceptance of the 
application. 

i) Does the prototyping tool support reuse? 
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Prototypes often represent a large investment, and in situations where a prototype is 
successful it should be possible to reuse the prototype in the remaining construction 
process. 
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Although prototyping tools may have the facility to provide reusable code for the 
system development, it is often available at the cost of having a slower prototyping 
tool. The reuse of code may not be a good idea since some of the design methods 
used for prototype development may not be suitable or desirable for application 
development. 

Another option which is supported by some tools is that certain prototyping 
components can be reused e.g. window definitions. The tool selected for 
prototyping should allow easy transfer of the required components into the 
development environment. 

j) Can the prototyping tool be used to design and build the front end? 

The prototyping tool could also be the tool that will be used to design and build the 
front end. Using the same tool eliminates double entry of repository information 
and reduces the chance of errors when prototype information is transferred to the 
application design phase of the project. 

k) Does the prototyping tool support functionality not provided by the construction 
tool of choice? 

If the prototyping tool provides functionality not available in the construction tool 
then standards need to be put in place to ensure that the development team only 
produce the prototypes using features that can be implemented in the development 
environment. The amount of additional effort required to develop features that are 
easy to implement with the prototyping tool but which require work-arounds in the 
construction tool should be a consideration. Prototyping features which cannot be 
delivered will result in failure to meet user expectations. 
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Application Logic Design 

Application Logic Design tools are used to graphically depict an application. These 
tools include application structure, module descriptions, and distribution of 
functions across client/server nodes. 

A variety of tools and techniques can be used for Application Logic Design. 
Examples are structure charts, procedure diagrams (module action diagrams), and 
graphics packages to illustrate distribution of functions across client and server. 

Application Logic Design functionality is also provided by a number of Integrated 
Development Environments (IDEs). 

With component-based development, Application Logic Design is performed 
through object and component modeling. The functionality is captured in use cases, 
scenarios, workflows and/or operations diagrams along with interaction 
diagrams/sequence diagrams. These are usually produced using MS Word, MS 
PowerPoint, ABC Flowcharter (Micrografix), or an object modeling tool. 

Implementation Considerations 

a) Is there a need for logic representation? 

Use Application Logic Design tools to graphically depict the logic of an application. 
This is a common requirement on most engagements. 

b) Is there some uncertainty about the validity of the business case? 

The Application Logic Design tools provide a means of confirming the complexity 
estimates and hence facilitate a revision of estimates before going into construction. 
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By confirming the validity of the complexity estimates, the business case is also 
confirmed. It is at this stage that the decision is made whether or not to continue 
with construction. 

c) Is performance modeling required? 

Application Logic Design tools can provide a basis for performance modeling, based 
on the processing ability of the CPU, parallelism, and pipelining. The tools can be 
used to graphically depict system complexity, from which a performance model can 
be derived. 

d) Is the programming team inexperienced? 

Application Logic Design tools provide a vehicle for communication from designer 
to programmer. This is particularly important when programmers are relatively 
inexperienced and need detailed guidance, which comes from the detailed design 
that is documented using these tools. 

e) Is system maintenance part of the project definition? 

Application Logic Design tools, and the designs that they contain, provide 
documentation of the system which will support maintenance in the long run. 

If the maintenance team is very experienced, or if the system is a throw-away 
prototype, which will not be reused or maintained in the future, then Application 
Logic Design tools may not be required. 
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Product Considerations 

a) Should the engagement team build a custom Application Logic Design tool or 
purchase an existing one? 

Engagement teams must determine whether standard design templates provided by 
vendors meet project needs, or if the architecture must provide custom solutions. 
CASE tools tend to provide standard Application Design documentation. Most 
custom solutions utilize word processing tools to build Application Logic Design 
shells for use by development teams. 

b) Are several tools to be used to provide Application Logic Design facilities? 

A single tool may not provide all the facilities required. The different tools must 
interface with one another in order to promote consistency of the Application Logic 
Designs. 

c) Does an existing tool provide the required functionality? 

The development team may require facilities to produce procedure diagrams, 
flowcharts, or pseudocode. These facilities may already be provided by existing 
tools, for example, pseudocode can generally be produced by an application 
development tool. 

d) Does the Application Logic Design tool reflect the close relationship between 
application logic and the user interface?. 

In a good GUI program design, the application logic is often closely linked to the 
user interface. A single design document capable of capturing this relationship could 
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serve as a key input into the programming process. Traditional tools only provide 
separate presentation design and application processing module design documents. 

Database Design 

Database design tools provide a graphical depiction of the database design for the 
system. They enable the developer to illustrate the tables, file structures, etc., that 
will be physically implemented from the logical data requirements. The tools also 
represent data elements, indexing, and foreign keys. 

Many data design tools integrate data modeling, database design, and database 
construction. An integrated tool will typically generate the first-cut database design 
from the data model, and will generate the database definition from the database 
design. 

With an object-based or component-based solution the data modeling task changes. 
In most cases, relational databases are still used, even where there are no 
dependencies on legacy systems. As there is an 'impedance mis-match' between an 
object model and a data model, a mapping activity must be undertaken. There are 
standard mechanisms for doing this. There are also tools on the market which allow 
the mapping of classes to relational tables, and which generate any necessary code to 
perform the database operations (e.g. Persistence, DBTools, ...). 

There is a tendency (especially when dealing with legacy systems) to treat data 
models and object models the same. It is important to recognize that at best, the data 
model represents only the static part of the object model and does not contain any of 
the transient or dynamic aspects. The physical data model may also change 
significantly (for DB optimization), further confusing the issue. 
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There can be performance problems with objects mapped to a relational database. In 
a worst case scenario, an object can be spread across many tables, with a single 
select/insert for each table, and as each object is loaded one by one, the performance 
becomes very poor. Some tools provide lazy initialization (only loading the parts as 
they are needed) and caching (minimizing DB hits). 

The current trend seems to be for object-relational databases, with vendors such as 
Oracle adding object features to their core products. Although the support provided 
at the moment is limited, it is likely that in future versions Java or C++ classes will 
be able to interface directly. 

Implementation Considerations 

a) Do the design ideas need to be communicated to a large team of developers? 

Database design tools are important where design ideas must be communicated to 
the development team. Where the development team exceeds ten people, this design 
must be formalized. Database design tools provide a graphic depiction of the 
database design for a system, whilst at the same time enabling the developer to 
illustrate tables and other structures that will be implemented physically. 

b) Is system performance a major consideration? 

Database design tools become especially important if performance is critical, since 
database design contributes substantially to the overall performance of the system. 
Database design tools provide quantifiable performance data which is a crucial 
component of the overall performance model. 
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Database Design tools also provide a means to model I/O on devices such as hard 
disks, optical drives, and tapes etc. This information can be used in a performance 
model. 

c) Does the project have multiple teams working on multiple functional domains? 

The database design component is important in the case where multiple teams are 
working on different functional domains, since they often model different parts of 
the database separately and then incorporate these models at the end into one large 
database model. Database design tools can be used to enforce consistency of the 
different database designs. 

d) Does the database include a very large number of tables and elements? 

Navigation through a large number of tables is complicated and can be simplified 
significantly if dedicated database design tools are used. 

e) Are there likely to be conflicting system requirements? 

Different teams or users may have different requirements which conflict. These 
requirements may have to be rationally traded-off against each other. Where these 
requirements are performance related, the trade-off can only be rationalized on the 
basis of a good database model. 



Product Considerations 



-262 - 

f) Does the product provide the following features? 

• Support for definition of DBMS advanced features (e.g. triggers, stored 
procedures, replication, application logic, application generation, referential 
integrity) 

• Support for versioning and change control 

• Cross platform and DBMS integration 

g) Should the database design tools support database construction? 

Many database design tools allow for database construction. Such tools may help 
translate a logical database design into a physical design, or they may generate Data 
Definition Language (DDL) code or Data Manipulation Language (DML) code. 
The advantage of using a tool that provides this facility is that it simplifies the 
transfer of design information into a physical representation and can be used to 
ensure consistency from design into construction of the database. 

Presentation Design 

Presentation design tools provide a graphical depiction of the presentation layer of 
the application, such as windows, dialogs, pages, navigation and reports. Tools in 
this category include window editors, report editors, and dialog flow (navigation) 
editors. Window editors enable the developer to design the windows for the 
application using standard GUI components. Report editors enable the developer to 
design the report layout interactively, placing literals and application data on the 
layout without specifying implementation details such as page breaks. The majority 
of these tools generate the associated application code required to display these 
components in the target system. 
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Dialog flow (navigation) editors enable the developer to graphically depict the flow 
of the windows or screens. 

The Control-Action-Response (CAR) diagram is a commonly used technique for 
specifying the design of GUI windows. It is typically developed using a matrix or 
spreadsheet tool such as Microsoft Excel. 

The majority of Netcentric systems use Web browsers to provide a common cross- 
platform user interface. Presentation design for this type of environment therefore 
entails the generation of HTML pages, often with additional components 
(JavaScript, 3rd party ActiveX controls, Plug-ins) providing enhanced functionality 
or media content. Many tools are currently available for designing and creating web 
content, although HTML remains the common denominator, at the very least as a 
placeholder for the content. 

In the case of systems published on the Internet, defining the target audience is less 
straightforward than in traditional systems, but equally important. Having a good 
understanding of the intended audience will be a big advantage when thinking about 
user interaction with the system, and therefore, the presentation layer of the system. 

Implementation Considerations 

a) Does the project want to use a single tool for prototyping and GUI design? 

Presentation design tools provide the ability to use a single tool for both prototyping 
and GUI design. This decreases the learning curve during design and permits 
components of the prototype to be reused. 
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b) Are user requirements clearly defined? 

c) Are numerous iterations of design anticipated? 

These tools make application development easier and faster through point-and-click 
capabilities and built-in functions. Reduction in the overall presentation layer 
5 design/development effort allows for more design iterations, and thus more chances 
for user feedback. 

d) Has a specific construction tool been selected for the project? 



If the tool to be used for construction is not known at design time then specific tools 
for presentation design are needed. 



10 e) Is the design complex? 




f) Does the design have to be presented to multiple users? 



g) Do the users have conflicting interests? 



h) Does the design have to be signed off? 



i) Does the design have to be maintained over time? 



15 



In these cases a dedicated presentation design tool can be used to provide 
maintainable documentation of the presentation design which can be used to clarify 
and communicate issues. 
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Product Considerations 

a) How much does the tool cost? 

Product components, maintenance agreements, upgrades, run-time licenses, and add- 
on packages should be considered. 

b) Will the design tool be used for programming of client applications? What 
programming language is supported? 

If the design tool is used for programming, there are several features of a tool that 
must be considered. These features can have an impact on the productivity of 
programmers, performance of the applications, skill sets required, and other tools 
required for development. These features include: 

• What programming language is supported? Is the programming language 
interpretive or compiled? Is it object oriented or a structured procedural 
language? 

• Does the tool support programming extensions to Dynamic Link Libraries? 

• What are the debugging capabilities of the tool? 

c) Will the tool be used with a large development team? 

If the development team is more than 5 people, a tool should provide support for 
multiple developers. This support includes features such as object check-in/check- 
out, a central design repository for the storage of application objects and user 
interface definitions, and version control. Additionally, the development team 
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should be able to cleanly divide the application(s) into pieces that can be worked on 
by multiple developers. 

d) If the tool is also going to be used for application development, how well does the 
tool perform during production? 

Computational, network, data retrieval, and display speeds differ for products. 
Factors to consider are whether the application will consist of heavy data entry, 
transaction processing, or a large user base. 

Does the product integrate with other tools and/or support other tools in the 
development and execution environments? 

It is important to determine how well the product integrates with other design and 
development tools, presentation services (graphics, multi-media, etc.), data access 
services (databases and database API libraries), distribution services (distributed TP 
monitor), transmission services (SNA, HLLAPI, etc.), data dictionary, desktop 
applications, and programming languages for call-out/call-in. Additional 
consideration should be given to add-on and third-party products/enhancements such 
as specialized widgets, report writers and case tools. 

e) Is the tool scalable? 

The tool should be scalable to support growth in application size, users, and 
developers. 

f) What functions are required in the control set? 

At the minimum, a tool should support basic widgets (push buttons, list boxes, etc.), 
window styles, (multi-window, multi-document, paned-window), and menu styles, 
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along with validation and inter-application communication. Consideration should 
also be given as to the extensibility of the toolset via add-ons and third party 
products. 

g) What databases are supported? 

h) What protocols are used to communicate with the database? 

Important considerations include the supported databases and protocols used to 
communicate with the databases. The tool must support the selected database. 
Additionally, if database selection may change, it is important that the tool have the 
ability to support other databases with minimal impact on the application 
development. Native database interfaces tend to have better performance than open 
standards such as ODBC. 

i) What level of technical support, documentation, and training is required to ensure 
the productivity of developers? 

The extent of support (on-site, phone, bulletin board, world-wide, etc.), quality of 
documentation, and availability and location of education/training should be 
considered. 

j) What type of learning curve is associated with the tool? 

Developers using the product should be able to become productive quickly. Factors 
which reduce the learning curve include an easy to learn and intuitive interface, 
thorough and clear documentation, and on-line help. 
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k) Can the tool be used for both prototyping and GUI design? 

The ability to use a single tool for both prototyping and GUI design will reduce the 
development learning curve. Tool integration with all other development tools 
should also be considered. 

I) What platform(s) are supported? 

The platform(s) that must be supported, i.e., MS-DOS, Windows, IBM OS/2, UNIX, 
or UNIX Motif, are an important consideration, as are any hardware restrictions. 

m) Is there a need for consistency across multiple screens or windows? 

Some presentation design tools provide the facility for reuse of elements. This can 
be used to enforce consistency across multiple screens and can accelerate 
development. This feature is not available in low-end presentation design tools, such 
as MS PowerPoint. 

One means of ensuring reuse is for the tool to support a central library of predefined 
widgets or screen elements. This library should be extendible and customizable, 
allowing developers to create new widget/element definitions or to enhance existing 
ones. 

n) Is multi-language support a consideration? 

Special characters, differences in field lengths, and differences in number formats 
are some of the things that contribute to the complexity of a multi-language 
application. Window and report design are among the areas affected by differences 
in the language used for presentation. 
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Strategies on how windows are displayed are affected if multi-language support is a 
requirement. Are separate windows painted for each language or are window literals 
dynamically replaced? The former will produce windows that are more visually 
appealing but requires more significant effort to create and maintain. 

The presentation design tools should facilitate documentation of these differences 
for design purposes and allow the design strategies to be implemented. 

o) Is the tool integrated with the repository of choice? 

The presentation design tools should be tightly integrated with the system 
components stored in the repository, such as windows, reports, screens, and other 
more abstract models to ensure consistency. 

p) Is a multi-media application to be developed? 

Touch screen hotspots, video clips, hypertext, pointer device hotspots and other 
similar design objects must be supported by the presentation design tool if the 
design is for a multimedia application. 

Communication Design 

An increasingly important aspect of system design is communication design. After 
the fundamental communication paradigms have been chosen, each exchange must 
be designed to allow for the detailed design of each module (clients, services, 
functions), and to lay the basis for more refined performance modeling. To ensure 
against interface problems, these tools should be tightly integrated with the design 
repository. One simple way to document communication interfaces is to define 
include files, which hold the interface definitions. 
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Implementation Considerations 

a) Is performance simulation or modeling required? 

Thorough performance simulation or modeling requires a communication model. A 
performance model is particularly important if the system is large, heterogeneous, 
and complex. 

A valid performance model can only be created once a detailed communication 
design has been developed for the system. The performance model is derived from 
the detailed communication design. Communication design tools provide a means 
of documenting the physical design of the system, such as protocol stacks, message 
sizes, routers, bridges, gateways, LANs, WANs, MANs, etc. as well as the logical 
design, both of which are used to develop the performance model and to simulate 
performance. 

b) Is the system migrating from a central to a distributed environment? 

c) Is the system migrating from a LAN to a WAN environment? 

d) Is the system migrating from a country wide WAN to a global network? 

When development takes place in a mainframe environment, performance is 
relatively predictable. In a distributed environment, response time is dependent on 
the communication design. 

Migrating from a LAN to a WAN, or from a WAN to a global network will 
drastically impact the performance of the system, and this type of migration requires 
the development of a complete communication design from which a performance 
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model can be derived. Thus, tools to facilitate the communication design become a 
critical part of the development architecture when migration of this sort is involved. 

e) Is high network performance required? 

Communication design tools are essential in developing systems where critical 
business operations have to have maximum availability and minimum down time. 
One of the primary contributing factors to high performance in client/server 
environments is a good network design. A good network design can only be 
achieved through a good communication design. 

Product Considerations 

a) Is the tool repository based? 

The best support for detailed communication design for a large development team is 
provided by a repository. Here the messages, calls, and queries can be modeled and 
designed as entities in their own right. These entities provide a necessary basis for 
performance and module design, which can be shared by all developers. 

b) Is there a need for a graphical depiction of the communication design? 

A graphical depiction of the communication design may be required. For simple 
designs, tools such as PowerPoint are normally adequate. Data flow diagrams may 
be used to show how clients send messages to services. The tools used should help 
developers to ensure that objects in the diagrams are linked to the actual objects 
(Windows, Services, etc.) in the repository. This will maintain consistency of the 
design documentation with the actual objects used in development. 
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c) Do existing tools provide the necessary functionality required to produce the 
communication design for the project? 

A simple and effective method of defining interfaces is by using include files to hold 
the interface definitions. The application development tools usually provide this 
facility. 

A spreadsheet package such as Excel may also be used to design message layouts. 

For simple graphical depictions of the communication design, a tool such as 
PowerPoint is adequate. 

d) Does the tool encapsulate knowledge of the services provided by the middleware 
layer? 

The middleware layer provides the basic functions for applications in a 
heterogeneous environment to interface with operating systems, networks and 
communication protocols. 

If the tools used encapsulate knowledge of the middleware services, low level design 
of communication (e.g. designing at the level of named pipes and sockets) need not 
be supported or investigated. The middleware component abstracts this level of 
detail so that the designers need not concern themselves with complex technical 
issues. 

Usability Test 

From a development perspective, systems that are designed and tested with usability 
in mind offer clear advantages. This is providing Usability Testing is executed from 
the user perspective, and from the very beginning of the development process. 
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Usability Testing can help developers: 

• Reduce risk by confirming that they are building the right solution 

• Identify new system requirements 

• Decrease development time and money by reducing rework 

• Achieve a smoother conversion, with less disruption to business 

Each system is designed to meet the unique requirements of its users, and therefore 
benefits from a different mix of testing techniques. In many cases, designers find 
that the best starting point is to build and test low-fidelity prototypes. These are 
paper-and-pencil versions of user interfaces that allow developers to demonstrate the 
behavior of systems very early in development. Before any code has been written, 
developers build prototypes on paper and test them with real users, simulating the 
human-computer interaction. Designs are adjusted and retested several times until a 
usable solution emerges. When it is time to begin coding, developers already have 
an excellent idea of how the system should work and what the users want. 

Once the user interface has been coded, the high-fidelity prototype is ready for 
online usability testing. The test results are compared with previous tests and routed 
back to the developers. If lo-fi prototypes were used earlier, the major design issues 
have already been resolved. Refinements at the "hi-fi" stage should focus on 
perfecting the details. 

In the later stages of development, usability laboratories can be extremely helpful for 
evaluating system design. Usability labs, which can be stationery or portable, rely on 
videotape and screen capture methods to record how users interact with prototype 
systems. Within a few hours of testing, lab administrators can create a highlights 
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videotape of problems that users encountered. These tapes can be used immediately 
by developers and project managers to modify the hi-fi prototype as required. The 
average usability test results in 70 to 100 specific recommendations for 
improvement. 

Remote testing, or telecasting, is an online variation of the usability lab. This still- 
emerging method relies on computer networks to conduct system evaluations. 
Remote testing enables developers to test a large number of users efficiently and 
without incurring travel expenses. 

Reverse Engineering (8130) 

Reverse engineering tools are used to capture specific, relevant functional and 
design information from a legacy system for use in a new, client/server system or to 
restructure the existing system for improved performance and maintenance. 

Interactive Navigation 

Developers use interactive navigation tools to identify requirements for a new 
system from the functionality and design of a legacy system. These tools enable the 
developer to interactively and graphically navigate the legacy system, determining 
the system's characteristics such as system structure, module flow, flow control, 
calling patterns, complexity, and data and variable usage. An alternate form of 
presentation is through reports. These provide cross-reference listings or graphical 
representations of control or data flows. 

Graphical Representation 

Graphical representation tools are used to display important system information in a 
form, which is easier to assimilate. These tools may, for example, produce structure 
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charts, database schema diagrams, and data layouts. They can also print matrices 
that indicate relationships between modules and files or between jobs and programs. 

Extraction 

An extraction tool, in conjunction with a repository population tool, enables the 
developer to reuse selected portions of a legacy system. The extraction tool can 
typically read and extract information from source code, screens, reports, and the 
database. The most common information extracted from a legacy system, however, 
is the data: record/table structure, indexes, and data element definitions. 

In component-based architectures, as systems are often built on top of legacy 
databases, some extraction tools allow generation of an object model from the 
legacy database data model (DDL). By understanding the E-R diagram represented 
by the database, it is easier to create an efficient persistence framework which 
isolates business components from a direct access to relational databases. Caution is 
required, however, as the resulting model is at best only partial, as an object model 
has dynamic aspects to it as well as static relationships, and may not correctly reflect 
the analysis performed in the problem domain. 

Repository Population 

The repository population tool is used to load the information from the extraction 
tool into the development repository. These tools convert the information from the 
legacy system into the syntax of the development tools repository. The extent of the 
information loaded into the repository is a function of the Information Model of the 
development tool repository. Information that is not represented in the development 
tool repository cannot be loaded into the repository. 
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Restructuring 

Restructuring tools are not analysis tools like the previous categories of reverse 
engineering tools, but design and construction tools. They enable the developer to 
rebuild a legacy system, rather than replace it. Examples of this type of process 
include restructuring spaghetti code with structured code, replacing GOTO's, 
streamlining the module calling structure, and identifying and eliminating dead 
code. 

Data Name Rationalization 

Data name rationalization tools extract information on variable usage and naming, 
and show relationships between variables. Based on these relationships and user 
input, these tools can then apply uniform naming standards throughout the system. 

Packaged Component Integration (8132) 

Packaged components are generally third party components that provide ready-made 
business logic that is customizable and reusable. These can range from simple 
components offering limited functionality (for example, worksheet or charting GUI 
components), to components that handle a significant portion of the application 
architecture (for example, data access components and firewalls). The advantage of 
using such components is that they have already been coded, tested, optimized, and 
documented. 

The fact that these components come from third-party software houses does not 
always guarantee their quality. In order to minimize the dependency of the final 
system on these components (thus reducing the impact of possible changes within 
the libraries), it is recommended that wrappers are written to enclose any third-party 
components. This way, if any changes are made to the internals of the components, 
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only the wrappers would be affected, allowing the application and architecture code 
to remain unchanged. 

Frameworks may be found on the market which provide generic components for 
general business processes such as general ledger, sales order processing, inventory 
management or product distribution. For example, IBM San Francisco offers 
business components for the Java environment (see 
http://www.ibm.com/Java/Sanfrancisco) 

Product Considerations 

a) Does the component require significant customization? 

When selecting components, it is important to get as close a match as possible to the 
functionality that is required. 

b) Will the vendor guarantee required functional enhancements? 

If functionality is missing from a component that cannot be added using the standard 
customization tools provided, it is vital to get a vendor guarantee that the 
enhancements will be made, and to agree on a deadline for these enhancements. 

c) Will the vendor guarantee consistency of all interfaces across future releases? 

The biggest danger in using packaged components is that the vendor will make 
changes to the component interfaces. When selecting packaged components make 
sure the vendor guarantees backwards compatibility of all the existing interfaces 
provided by the component. If this is not the case, it will entail much reworking of 
the application code in order to be able to take advantage of (potentially important) 
upgrades to the component. 
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d) What are the performance implications of using a packaged component? 

Components are often developed with a preferred platform in mind. Components 
optimized for one platform may have severe performance problems on others. If 
performance is a factor (and it nearly always is) ensure that components are 
designed specifically for the platform of the target system. 

e) Does the component provide standard or proprietary interfaces? 

When choosing between packaged components, always choose standard interfaces 
over proprietary ones. It will always be easier to customize and interface a 
component whose language is known to the development team, rather than one 
which requires developers to learn a new proprietary language. 

Customization 

Packaged components usually do not provide the exact functionality that is required 
of the target system because they are created by third parties. They may have to be 
configured in order to behave in the desired fashion. The majority of packaged 
components allow one of two methods of customization - either by using standard 
construction tools (such as an editor and a C compiler), or by using proprietary 
toolkits provided by the vendor. 

Implementation Considerations 

a) What level of support is provided by the component vendor? 

It is vital that the vendor provides an appropriate level of support for the component 
such as documentation, telephone support, remote support, training, and onsite 
support. It might also be necessary to include vendor developers on the Application 
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team. This is especially important where component customization relies on 
proprietary toolkits. 

Construction (8134) 

Construction tools are used to program or build the application: client and server 
5 source code, windows, reports, and database. Along with the onset of Visual 

Programming, the more traditional form of construction tools have been superceded 
by Integrated Development Environments (DDEs) which take all the basic 
components required for construction, and integrate them into a single system. 
Although IDEs are now the preferred tools for most construction, the components 
10 that make up these tools remain the same - Source Code Editor, 

Compiler/Linker/Interpreter, Generation Tools and Debugging Tools. 

Visual Programming tools, initially associated with the rapid development of the 
client-side of client/server applications, have now matured and expanded their 

domain4o-eover-entire-eli^ 

15 development (e.g. visual Java DDEs). 

IMPORTANT: While IDEs provide the basic components for construction, not all 
the functionality offered by the components listed here is provided (for example 
IDEs do not generally provide Help text generation or DDL generation). DDEs can 
usually be customized in a way that other tools (Version Control, Generation, 
20 Repository Access etc.) can be integrated. It is necessary to plan time for this 
upfront. It should not be left to the developers to do this individually. 

In addition to the standard construction components, a new set of utilities exist 
which can help increase the quality of code generated by developers. QA Utilities 
verify the quality of constructed code, and its conformance to standards set down for 
25 the development environment. 
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It is important to ensure that developers use tools that are standard to the 
development environment. Now that Internet access is a standard facility for 
developers, there may be the tendency for people to download their own preferred 
tools, or upgrades to standard tools. This not only affects the management of the 
development environment, but could easily result in the generation of code that is 
incompatible with the rest of the code in the development system (for example, 
consider the effect of developers on the same team using tools which employ 
different version of the JDK). 

Product Considerations 

a) What size is the development team? 

When IDEs were first developed, they were targeted at individual developers. This 
means that support for team development is still not fully mature in the majority of 
IDEs, although some are closely integrated with third-party configuration 
management packages. When selecting an IDE it is important to ensure that team 
development is sufficiently catered for. 

b) On what platform is the system expected to run? 

c) Is the target system expected to run on multiple platforms? 

The construction tools selected must be able to support the target platform(s) of the 
system to be developed. 

Source Code Editor 

A source code editor is used to enter and edit source code for the application. 
Complexity varies from simple ASCII text editors to fully integrated editors such as 
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those provided by Integrated Development Environments. Typically however, they 
are linked with a debugger so that coding errors which are identified during 
compilation can be more easily corrected, since the error and the source code 
generating the error can be viewed simultaneously. 

Other features include: 

• Dynamic syntax checking, improving productivity by detecting errors as they are 
made, rather than at compile time. 

• Color coding, which automatically applies different colors to text depending on 
its type or context (e.g. comments, variables, reserved words etc.), thus making 
the code more readable. 

• Automatic layout, which indents code depending on its logical level (e.g. loops, 
conditionals etc.) 

On the whole, these features will help ensure that code developed by the team is 
following project standards as opposed to individual programming styles. 

Implementation Considerations 

a) Web-based development 

Due to the tendency of Web-based applications to combine multiple components 
(such as HTML, Javascript, Java applets, CGI scripts etc.), numerous source code 
editors may be required for the development of any single web application. 
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Product Considerations 

a) How well integrated is the editor with other tools in the development 
environment? 

The level of integration with the rest of the environment is an important 
consideration when selecting a source code editor. Most editors now come as part of 
an IDE, and are therefore fully integrated. 

b) Does the editor support multiple languages? 

Some IDEs provide support for many languages using the same interface (for 
example, MS Developer Studio supports C, C++, Java, Fortran). This has the 
advantage of providing the user with a common approach to coding, regardless of 
the language being used. 

c) What features are provided by the editor? 

As mentioned in the component description, many features may be provided by the 
editor, which can save time and improve code quality. A feature-rich editor is 
therefore often worth the investment. 

d) Is the product easy to learn and use? 

The source code editor should be easy to use with little or no training required. 
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e) Is an acceptable source code editor already provided by the operating system or 
other tools in the development environment? 

Most Development tools and operating systems already include a source code editor. 
These source code editors are usually just simple text editors. 

f) What is the amount of the application code? 

Some source code editors may not have the ability to handle extremely large files 
while other tools are built specifically for that purpose. 

Compiler /Linker /Interpreter 

This component is responsible for taking raw code (usually in ASCII format) and 
creating the necessary object, library, byte-code, or executable files that become 
components of the final system. The actual tools required depend on the 
development language, but always consist of one or a combination of the following 
components: 

• Compiler 

• Linker (preferably incremental - the linker can substitute a new version of a 
single module rather than having to re-link the entire program) 

• Interpreter, which can speed up the test/correct cycle by eliminating the compile 
and link steps 

In the majority of Integrated Development Environments, the Compiler, Linker 
and/or Interpreter are included as an integral part of the system. In addition, the 
management of compilation and linking is automated using MAKE utilities which 
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understand the dependencies between modules in the system. This allows the 
system to trigger all necessary re-compilation and re-linking when a module in the 
system is changed, thus avoiding the time consuming task of re-compiling and re- 
linking the entire system. 

Product Considerations 

a) Is the tool easy to use? 

The tool should be relatively easy to use in order to reduce the learning curve. 

b) Does the tool support the platform in the development environment? 

The compiler/linker/interpreter tool must be compatible with all the platforms upon 
which the application is being developed. Besides compatibility, tool performance 
may be platform dependent. 

Source Code Debugger 

A source code debugger is a tool used to unit test a program. This tool provides 
information about the activity of programs and systems, enabling automatic analysis 
and diagramming, assisted code tracing, editing capabilities, and automatic 
documentation. The debugger allows the developer to enter program break points 
and step through a program, tracking the progress of execution and identifying errors 
interactively. It is typically used in conjunction with the source code editor so that 
coding errors identified can be more easily corrected, since the error and the source 
code generating the error can be viewed simultaneously. 

Symbolic source code enables easier identification of where errors occur. 
Preferably, the debugger should be flexible enough to work with any combination of 
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compiled modules and source modules. In addition, the debugger should be able to 
handle calls to the database and to other modules. 

Product Considerations 

a) What testing team factors should be considered when using a source code 
debugging tool? 

Communication between development team and testing team 

A code analysis tool can help the testing team detect unreported changes in the 
application code, and therefore help alleviate possible bad communications between 
the development and testing teams. Thus, bad communications between teams will 
still influence positively the decision to use code analysis tools. 

Generation 

Generation tools include: 

• Shell generation 

• Make file generation 

• Window/page generation 

• Data Definition Language (DDL) generation 

• Data Manipulation Language (DML) generation 
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• Code generation 

• Include file generation 

• Help text / module description generation 

• Trace code generation 

Shell generation is the process of generating a starting point for programming. Shell 
generation is typically repository-based but can also be based on interaction with the 
programmer, where the generation utility requests key information about the 
program, and generates a starting point as a result of this. Key information (whether 
obtained from the repository or through a dialog with the programmer) may include: 

• Data base tables accessed 

• Methods and attributes defined (for objects) 

• Interface information 

Based on this information, the generator selects the appropriate include files and 
creates skeleton code which may be used as a template for the programmer. This 
template may also include audit history for the module and standard code such as 
error handling. 

Make file generation is integrated into the majority of DDEs 

Window/page generation (which is an integral component of Visual programming 
tools) allows the developer to rapidly design windows and pages using a point and 
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click graphical interface. The relevant source code is subsequently generated from 
these designs. 

The generation of DDL and DML is often hidden from the developer by using data 
access functions or objects, provided by a large proportion of DDEs (e.g. MFC, JDK) 

Help text and module description generation (not usually provided by IDEs) 
analyzes developers raw code (including comments) and creates descriptions which 
may be used by developers to understand the contents of modules or objects. This is 
particularly useful for component-based development, where methods and attributes 
of objects may be automatically documented. 

Trace code generation allows the insertion of traces into raw code in order to aid 
debugging. 

Implementation Considerations 

a) Does the project want to isolate developers from the technical environment as 
much as possible? 

b) Are there a large number of developers which makes it difficult to enforce 
standards and consistency among developers? 

Generators are typically used to enforce and maintain consistency throughout an 
application. The main benefit is a reduction in training. In addition, the code 
generated will automatically be checked for errors, shielding the developers from 
many complexities of the technical environment. 
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c) Are there a large number of developers or a large amount of code? 

d) Can significant time be saved by creating generators to generate code for reuse 
and regenerated code to propagate changes? 

Generators are used to leverage the powers of code reuse and code regeneration. 
The ability to reuse code reduces both the time and resources required on a project. 
Code regeneration eases maintenance issues by propagating changes throughout 
multiple sections of code. 

Product Considerations 

a) Can the generation tool provide code which meets performance requirements? 

The code/applications generated by the tools vary in performance. Optimized code 
usually results in faster run times. It is important to identify the high priority 
components that will benefit most from the tool. 

b) Should the engagement team build a custom generation tool or purchase an 
existing one? 

The decision to custom build or to buy available case tools must be determined by 
the development team. Most generators are usually custom built because often the 
technical environment and architecture have custom components that cannot be 
handled by a package generator. Associated with custom building are the issues of 
added cost and development time, but performance can be closely monitored and 
changes performed on the spot. 
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c) Does the generation tool support the development and execution platforms? 
The tool must support the current or proposed platform. 
QA Utilities 

QA Utilities verify the quality of completed code, and that it conforms to project and 
international standards. These types of tools include the following: 

• Code Analysis - Code analysis provides the objective information and metrics 
needed to monitor and improve code quality and maintenance (e.g. static 
analyzer, documentor, auditor). 

• Code Error Checking - Checks code for common errors (e.g. syntax errors, 
uninitialized and badly assigned variables, unused variables) 

• Code Beautification - Re-formats code in order to make it easier to read and 
maintain. 

• UNIX Portability Checking - Checks compliance with basic portability standards 
- particularly with programming standards that ensure portability across UNIX 
platforms (e.g. POSIX compliance and OS/2-to-Windows portability). 

• 1 00% Pure Java Checking - Checks that Java code conforms to the 1 00% Pure 
Java standard. 

Code / Object Libraries 



Code and Object libraries provide the developer with ready-made components (such 
as GUI components or simple utilities), which may be integrated into architecture or 
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application code. The advantage of using such components is that they have already 
been coded, tested, optimized, and documented. 

Code and Object libraries may be differentiated from packaged components in two 
ways: 

• They contain little or no business logic 

• Source code is usually provided (as opposed to the *black box* component 
approach) 

That these libraries come from third-party software houses does not always 
guarantee their quality. In order minimize the dependency of the final system on 
these components (thus reducing the impact of possible changes within the 
libraries), it is recommended that wrappers are written to enclose any third-party 
code. This way, if any changes are made to the libraries, only the wrappers would be 
impacted, allowing the application and architecture code to remain unchanged. 

Implementation Considerations 

a) Does the object/library really need to be wrapped? 

It may not always be prudent to wrap all third party objects/code that are to be used 
on a project. Sometimes the cost involved may outweigh the value of wrapping an 
object/code. As objects/code become more complex, with more functions/interfaces, 
then the value of wrapping them becomes more tangible. 
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Media Content Creation 

As systems become increasingly user- facing, it is important to design user interfaces 
that are not only functional, but also engaging and informative. This is especially 
true of Internet and kiosk-based systems, where users have a notoriously short 
concentration span. 



This requirement for more attractive user interfaces has triggered the evolution of 
media-rich applications, the development of which requires new tools and processes, 
and brings with it a whole new set of issues. 

Media content can be broken down into three major media types, each with its own 
set of tools: 

• 2D/3D Images/Animation 

• Video 

• Audio 

2D/3D Images/Animation 

Tools to handle these images range from simple paint packages to highly complex 
multi-layered animation graphics packages. The images created by these tools may 
be pixel-based (bitmaps) or vector-based, each with their own advantages. 

• Pixel-based tools (traditional graphics and image processing tools) offer more 
image flexibility especially in terms of color gradation and shading, but produce 
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relatively large files. This format is therefore useful where the use of high- 
quality textured images, or highly colored images is important, but where file 
storage and transmission is not an issue (where the media content is local to the 
client application, such as in a kiosk). 

• Vector-based tools (where the image is defined by formulae rather than pixel 
position) offer much smaller file sizes, and dynamic image re-sizing, while 
producing excellent print quality, but cannot easily handle shading and color 
gradation. This format is more appropriate where file size is an issue (web 
pages). 

Video 

The high cost and complexity of video production equipment, along with the skills 
required to manage the process of video production mean that it is usually 
outsourced to a third party. It is important however that the personnel charged with 
creating video content are an integral part of the Application team. 

Audio 

The tools required for creating audio content depend on the quality required, and 
whether or not the content is original. For 'sound bites' or pre-recorded audio, simple 
desktop audio editing applications are adequate. For high-quality original content, a 
professional recording studio is recommended. Again, if third parties are involved, it 
is important that they are fully integrated into the team. 

For both image and audio, it is possible to purchase re-usable content from agencies, 
usually delivered in the form of CD-ROMs. 
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NOTE: Tools required to store and manage media content (and storage formats) are 
discussed in Tools - Information Management - Media Content ManaRement 

Test (8136) 

Testing applications (client/server or Netcentric) remains a complex task because of 
the large number of integrated components involved (for example, multiplatform 
clients, multiplatform servers, multitiered applications, communications, distributed 
processing, and data), which, in turn, results in a large number and variety of Testing 
tools. 

For any large scale testing effort, it is vital to have a repository that is capable of 
managing the data required by each of the test subcomponents. The repository 
should manage the following entities: 

• Test conditions 

• Test cycles 

• System Investigation Requests (SIRs), triggered by a deviation of actual results 
from those expected 

• Test data 

• Requirements 

Within the repository, the following relationships between entities must also be 
managed: 

• Test cycle and the system component to which it refers 
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• Test condition and the test cycle it belongs to 

• Requirement and the test condition that tests that requirement 

These relationships make it possible to analyze efficiently the impacts of change and 
to document the state of system test. For example, the number of outstanding SIRs 
per cycle can easily be provided based on these relationships. 

In some cases, the mentioned entities and relationships cannot be managed within 
the repository, and may have to be modeled outside the repository (for example, in a 
teamware database). In this case, the link between the repository and the external 
tools must be provided by a judiciously chosen set of procedures and custom 
integration tools. 

Component-based development may have an impact on the way in which testing 
should be performed. 

A number of firm initiatives have conducted considerable research into the field of 
testing: 

• Year 2000 Testing Contacts and KX Resources 

• The Technology Library contains further information including tool evaluations, 
practice aids, and newsletters 



• Integrated Testing Environment Job Aid 
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Product Considerations 

a) When should vendor tools be used in the testing process? 

Vendor tools are more appropriate when the requirements are totally dependent on 
the software development platform. Moreover, when the technology evolves too 
quickly, it requires a software organization to handle the changes. 

Test Data Management 

Test Data Management tools allow developers to create and maintain input data and 
expected results associated with a test plan. They include test data and archiving 
tools that assist in switching between cycles and repeating a cycle based on the 
original data created for that cycle. 

Test Data Management functionality may be provided by the following tools: 

• Test data generation tools - usually generate test data by permutation of values 
of fields, either randomly or systematically. 

• Test design repository tools - facilitate structured design and maintenance of 
test cases. They help the developer find existing test cases, cycles, and scripts 
that may be appropriate for reuse. 

• Data management tools - provide backup and restore facilities for data. They 
also provide configuration management for multiple versions of data, 
maintaining consistency among versions of test data. 
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Implementation Considerations 

a) What guidelines should be followed when creating component and assembly test 
data? 

To minimize testing errors when creating component and assembly test data, follow 
the guidelines provided by the AC Methods job aid for quality test data. Follow the 
doclink to view the Tester's View of the Methods . 

Product Considerations 

a) What testing team factors should be considered when using a Test Data 
Management tool? 

Size of the testing team 

The larger the testing team, the more benefits will be derived from using a Test Data 
Management tool (easier control over the test data for the various testers), a 
configuration management tool (easier control over all system configurations and 
component versions), and a test plan management tool (easier control over all test 
cycles, subcycles, their execution statuses, and so on). 

b) What engagement factors affect the use of Test Data Management tools? 
Risk rating of the engagement 

In general, management and planning tools help better address the engagement risks. 
A high risk rating for the engagement will affect positively the decision to use tools 
such as test planning, Test Data Management, problem management, and 
configuration management. 
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Criticality of the engagement 

In general, management and planning tools help better manage the engagement and 
ensure the timely delivery of a quality system. Therefore, dealing with a highly 
critical engagement will most likely affect positively the decision to use tools such 
5 as test planning, Test Data Management, problem management, and configuration 
management. 

Test Data Manipulation 

Test Data Manipulation tools are used to create original test data and, sometimes, to 
modify existing test data. Such modifications may be needed to process a change in 
the database schema and to correct intermediate results in order to complete a test 
cycle. Some test data manipulation tools generate test data very effectively. 

Test Planning 

A Test Plan consists of several components: 

• Test schedule 

15 • Test execution tracking 

• Test cycles 

• Test scripts 



C3 

fe J3. 

a 

rlj: 

m 

.S3, 

5 



• Test conditions 
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• Test condition generation 



• Input data 

• Expected results 

Test Planning definition and maintenance tools define and maintain the relationship 
5 between components of a Test Plan. 



["« Implementation Considerations 

H 

□ a) What guidelines should be followed when assembly testing the technology 

1* architecture? 

M; 

jij When deciding which areas of the technology architecture to test, follow the 

rO 10 guidelines provided by the AC Methods job aid for technology architecture 

' jj; assembly testing. To view the guidelines, follow this doclink to the AC Methods job 

*s3: aid. 



b) What guidelines should be followed when creating test scripts? 



15 



When preparing to test system components, scripts can be used to verify that the 
system design specifications are properly implemented. An AC Methods job aid 
provides guidelines for creating product test scripts. 
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c) What guidelines should be followed when creating test cases for the component 
test? 

When preparing component test data, the AC Methods checklist helps ensure that all 
cases are thought up so that component testing is complete. To view the test case 
5 checklist follow the doclink. 

d) What components interface with the Test Planning component? 

The following components interface with the Test Planning component: 

Tools - System Building - Test - Test execution . This interface relates to the actual 
Test Planning scripts for an automated script playback capability. The scripting tool 
10 can be call directly from the Test Planning tool, which runs it or loads it to the target 
platform. More generally, all scripts, and actual results should be linked to the 
cycles. 



ru 

yj. Tools - System Building - Test - Test Data Management . Before beginning the 

H - { cycle, the transfer, load, and refresh of test data can be run from the Test Planning 

15 tool. 



Tools - Information Management - Repository Management . Each conversation, 
dialog, or executable tested in a cycle can be cross-referenced so that it is possible to 
know from the design where a functionality is tested. 



20 



Tools - Configuration Management . Each conversation, dialog, or executable tested 
in a cycle can be cross referenced so that it is possible to know from the design 
where a functionality is tested. 
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e) What is a repeatable test model? 

f) What is the importance of a test database? 

g) What is the team member retention with a repeatable test? 

h) How does a repeatable test model affect testing automation? 

The following is an overview of the repeatable test model as documented by the 
Reinventing Testing Project (RTP). 

A repeatable test model consists of tests that can be easily executed by staff who 
have little or no experience of the application being tested. A repeatable test script 
provides the detailed steps necessary to test the functionality. In addition, the script 
provides the tester with detailed expected results to verify the operation of the test 
script. 

In order to plan detailed script steps and expected results, it is necessary to know the 
test data. A large portion of the test data will typically be contained in test 
databases. These databases are called baseline databases, and are critical for a 
repeatable test model to exist. Baseline databases can be developed automatically 
(through execution of online activity in the system), manually (through test data 
manipulation tools), extracted from production databases, and so on. Once the 
baseline databases are selected and created, the repeatable test model can be 
developed. As the test model is based upon these databases, the impact on the test 
model of any changes to the baseline databases must be analyzed. 



With a repeatable test model, most of the team members' knowledge is captured in 
the tests. Retention of team members is therefore far less critical than with a non- 
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repeatable test model, and expected costs of training new team members are 
reduced. 

If the application does not change, repeating the tests yields the same results every 
time, given the same baseline databases. To remain repeatable, a test model must be 
maintained to reflect changes made to the application (fixes, isolated enhancements, 
new releases, and so on). 

To ensure the quality of the application as well as testing efficiency and 
effectiveness over time, the tests contained in the test model must be repeatable. 
Automation facilitates the engagement's ability to execute a repeatable test model. 
The decision to automate the test execution only affects whether the tests will be 
repeated manually or automatically. 

Automating the execution of a non-repeatable test model is a waste of resources, as 
the test tool will not be able to re-execute the tests automatically or perform full 
regression tests with little effort. Little or no benefits will be achieved from 
automation. 

Product Considerations 

a) Has RTP (Reinventing Testing Project) developed a test plan management 
system? 

b) What tools can be used for problem tracking? 

The RTP Tools Development team has documented their evaluation summaries of 
the internal test plan management system. The following is a brief description of the 
product. To view more detailed information, follow this doclink to the RTP Tools 
Initiative document. 
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The Test Plan Management System is an online GUI application that is used to 
facilitate the creation and maintenance of test models and to support the planning 
and performing of each test stage. Each test model is stored in a central repository 
accessible by all team members. 

Any test model data must be manually entered in the system or copied from a 
previously entered test model. 

Multiple test models can be accessed or viewed at one time. 

In addition, the TPMS provides the capability to research previously entered test 
elements through online queries. 

A reporting option is planned to produce metrics and management type reports. 

c) What testing team factors should be considered when using a Test Planning tool? 
Size of the testing team 

The larger the testing team, the more benefits will be derived from using a Test Data 
Management tool (easier control over the test data for the various testers), a 
Configuration Management tool (easier control over all system configurations and 
component versions), and a Test Plan Management tool (easier control over all test 
cycles, subcycles, their operating statuses, and so on). 

d) What engagement factors affect the use of Test Planning tools? 
Risk rating of the engagement 
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In general, management and planning tools help better address the engagement risks. 
A high risk rating for the engagement will affect positively the decision to use tools 
such as Test Planning, test data management, problem management, and 
configuration management. 

5 Criticality of the engagement 

In general, management and planning tools help better manage the engagement and 
ensure the timely delivery of a quality system. Therefore, dealing with a highly 
critical engagement will most likely affect positively the decision to use tools such 
as Test Planning, test data management, problem management, and configuration 
management. 

e) What application factors should be considered when using a Test Planning tool? 
Starting point of automation in the development life cycle 

If the testing process is to include the use of a test plan management tool, test model 
components may be more easily reused across test stages resulting in time and cost 
savings during Test Planning and preparation. This obviously has a positive 
influence on the decision to use the test plan management tool. 

Test Execution 

Test Execution tools support and automate the conduct of system tests. Test 
Execution support includes the tools required to: 

20 • Extract input data and expected results from the repository 

• Load this data into the appropriate Test Execution tools 
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• Automate the test 

Such tools include dynamic analyzers and execution logs. The Test Execution 
platform may differ from the development platform if development is conducted in 
one environment (for example, Windows NT workstations) and deployed on a 
5 different environment (UNIX workstations). 



A typical Test Execution tool supports test scripting and playback. These tools 
program or record the running of a test plan in an online environment by capturing 
^ key stroke sequences, mouse clicks, and other actions. They then record them in a 

^3 script. Once the script is programmed or recorded, it can run repeatedly on the same 

H : 10 application, effectively emulating the user. While defining the script takes some 

time, it saves tremendous effort when cycles must be re-run, particularly after 
7> relatively small changes (for example, the format of an output field is modified). 

I When the application is modified, the script can be updated directly without re- 

=y entering long sequences of user input. This makes it easier to prepare for regression 

rO 15 testing. Scripts may also be used for stress testing, where a single machine can run 

Til 

yj scripts simultaneously, emulating large numbers of users. 

Implementation Considerations 



a) What development approach factors should be considered when automating Test 
Execution? 

20 Reinventing Testing Project (RTP) has identified the following factors that either 
contribute to or take away from the successful implementation of an automated Test 
Execution tool. Further detail is available through RTP's Test Automation Strategy - 
Version 1.1 . The type of system development approach to be considered is: 



Maturity of the testing process 
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• Number of technical platforms 

b) What testing tool factors should be considered when automating Test Execution? 

RTP has identified the following factors that will either contribute to or take away 
from the successful implementation of an automated Test Execution tool. Further 
detail is available through RTP's Test Automation Strategy - Version 1.1 . Testing 
tool factors to be considered include: 

• Cost of testing tools (including training and support) 

• Cost of test model maintenance (including test data) 

• Testing tool ability to work with GUI application builder 

• Vendor support capability 

• Proximity of vendor support personnel to the project site 

• Availability of tool support person on the testing team 

c) What engagement factors should be considered when automating Test Execution 

RTP has identified the following factors that will either contribute to or take away 
from the successful implementation of an automated Test Execution tool. Further 
detail is available through RTP's Test Automation Strategy - Version LI . 
Engagement factors to be considered include: 



• Fixed fee engagement 



• # 
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• Risk rating of the engagement 

• Criticality of the engagement 

• Risk of not automating testing 

d) What application factors should be considered when automating Test Execution 

RTP has identified the following factors that will either contribute to or take away 
from the successful implementation of an automated Test Execution tool. Further 
detail is available through RTP T s Test Automation Strategy - Version 1.1 . 
Application factors to be considered include: 

• Application life expectancy 

• Number of planned releases 

• Use of application software packages 

• Frequency of upgrades in application software, system software, and hardware 

• Stability of the application 

• Starting point of automation in the development life cycle 

• Scope of the test automation 



• Number of passes per test cycle 
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e) What testing team factors should be considered when automating Test Execution 

RTP has identified the following factors that will either contribute to or take away 
from the successful implementation of an automated Test Execution tool. Further 
detail is available through RTP's Test Automation Strategy - Version 1.1 . Testing 
team factors to be considered include: 

• Willingness and ability to maintain the test model 

• Communication between development team and testing team 

• Control over the test environment 

• Acceptance of automation (attitude toward change) 

• Experience with test automation 

• Experience with the testing process used on the engagement 

• Experience with specific testing tools 

• Anticipated learning curve with automated testing tools 

• Experience with the technology used on the engagement 



• Size of the testing team 
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Performance Management 

Performance Management tools support application performance testing. Owing to 
the large number of components in modern systems, performance modeling can be a 
complex task and requires tools to effectively manage the process. These tools 
monitor the real-time execution and performance of software. They help to 
maximize transactions and response time to the end user. They are also useful in 
identifying potential bottlenecks or processing anomalies. 

In the case of Internet-based applications, as the Internet is not a controlled 
environment, performance management tools can only measure performance within 
the domain of the controlled environment (up to the Internet Service Provider). 
However, in the case of intranet-based systems, where the environment is controlled 
from end-to-end, Performance Management may be performed across the entire 
system. 

Emulation 

Emulation tools emulate components that are part of the target environment but are 
not in the development environment. These emulation tools include: 

• Target platform architecture components, including both custom infrastructure 
and system software products such as an X-window emulator on a PC to access a 
Unix platform. 

• Stubs, which emulate subroutines in a minimal fashion. 

• Harnesses and drivers, which call up a module and emulate the context in which 
the module will be called in the production environment. 



* • 
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Test Result Comparison 

Test Result Comparison tools are utilities used to compare expected and actual 
results. These tools outline the differences between actual and expected results by 
comparing files and databases. Most of these tools offer functionality such as byte- 
by-byte comparison of files and the ability to mask certain fields such as date and 
time. 

Test Coverage Measurement 

Test Coverage Measurement tools are used to analyze which parts of each module 
are used during the test. Coverage analyzing tools are active during program 
operation and provide comprehensive information about how many times each logic 
path within the program is run. This Test Management and Quality Management 
tool ensures that all components of an application are tested, and its use is a vital and 
often overlooked component of the test process. 



SIR Management 



SIR Management Tools help track each system investigation request from problem 
detection through documentation resolution. 



# • 
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OPERATIONS ARCHITECTURE FRAMEWORK (9300) 

Figure 93 illustrates an operations architecture framework according to one 
embodiment of the present invention. 



Operations Architecture 

The Operations Architecture is a combination of tools, support services, procedures, 
and controls required to keep a production system up and running efficiently. 
Unlike the Execution and Development Architectures, its primary users are the 
system administrators and the production support personnel. 

The following databases provide information on the Operations Architecture and list 
requirements and current tools solutions for the managing of the various Operations 
Architecture areas. All areas of the Operations Architecture have the appropriate 
MODE sub-functions listed, along with requirements for management solutions and 
current tools that assist and automate management solutions. 



Cautions and Caveats 

Unlike the Application and Execution Architectures, every function of the 
Operations Architecture must be reviewed. All components of the Operations 
Architecture are integral to the successful management of a distributed environment. 
Any processes, procedures, or tools developed or chosen as an operational 
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management solution for a specific operational area must be able to integrate with 
any existing or planned process, procedure, tool solutions for other Operations 
Architecture areas. 

While the tools data and suite information was current and accurate at the time of 
publication of this document, there is no guarantee that that information is still 
accurate, or that the vendor is still in business. It is imperative that the following 
actions are taken when choosing a tool-based solution: 

o determine that the vendor is still a viable candidate (i.e. still in business, 
good recent product support track record) 

o verify the version of the tool to be installed will still provide the management 
solution required 

o verify the tool(s) will integrate with existing tool(s) 

o verify the tool(s) will integrate with other planned tool(s) acquisition(s). 



General Implementation Considerations 

Some key design decisions are specific to the design of certain functions, while 
others apply more generically across every function. This section presents the 
generic key design questions. Key design decisions that relate specifically to a 
function are presented in each of the subsequent functional grouping chapters. 

The following generic decisions impact need for specific components: 
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When and how frequently, does the function need to be performed? 

The timing and frequency of each function may have an effect on its staffing, the 
tool(s) required, the capacity of systems and networks needed to support the tools. 

Who will be performing the function? 

Responsibilities need to be defined for each function, as the set up tasks will differ 
dramatically depending on whether the function is to be performed in-house or 
outsourced. In addition, the individuals who will be performing the function should 
be involved in the design of how the function will be performed. 

Will the function be centralized or distributed? 

Central control will mean a stronger focus on remote management, with skills 
focused in one place, whereas distributed control will mean skills will need to be 
more widely dispersed. Distributed functions may require less powerful tools due to 
their placement. 

Will the solution be manual or automated? 

A number of functions could be managed manually, especially if the functions are 
not directly related to the systems, or are performed infrequently. Many of the 
functions, however, require an interface to the systems, or involve large volumes of 
data. 

Is integration with any existing systems required? 

If integration with existing systems is necessary, hooks may need to be built into 
both the existing and new systems. 
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What are the data sharing requirements with other functions? 

Integration between functions will either require a tool capable of supporting both 
functions, or hooks between tools. 

What are the expected data / transaction volumes, and how much historical data will 
be required? 

Volumes of data, both real-time and historical, will have an impact on both system 
and network sizing. 

What platform /protocol constraints exist? 

Platforms and protocols are central both to the overall approach as well as the 
selection of tools to support the individual functions. 

Is the intention to use tools or to custom develop some or all of the functions? 

The choice of tools in the marketplace is increasing, but custom development may 
still be required. This decision will impact how the function is established initially 
as well as its ongoing support and maintenance. 

Will existing data/databases be used, or will data be built from scratch? 

Many of the functions may already exist within the clients environment. As such, 
data which is necessary for supporting the system may already exist. If so, it must 
be determined whether or not the existing data can be used, either in its original or a 
converted state. 
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General Product Selection Considerations 

It is important to note that there may be requirements which cannot be met by any 
tools. In this case, in-house development may be an alternative. This approach is 
likely to be more expensive, however, and more difficult to support the long term, 
and thus should usually be avoided if possible. Were possible, the tool with the 
closest match should be purchased, and customized to meet the necessary 
requirements. 

Some additional considerations are outlined below: 
Central vs. Distributed Control 

The answer to this question may limit the selection of tools as not all tools are 
capable of controlling functions remotely. If control is centralized, technical 
expertise at distributed sites will not be necessary. This may, however, mean that a 
more complex, expensive tool is required. 

If control is distributed, technical expertise will be needed at remote sites, and there 
is the potential for problems with the interfaces between tools. 

Platform Constraints 

Systems-based tools (e.g., for monitoring or control purposes) will clearly be 
platform dependent. Functional tools (e.g., to support Incident Management or 
Change Control), however, can run independently from the systems tools and may 
only need to run on a limited number of systems. 
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Integration with other Functions 

Integration between some of the functions is highly desirable. Integrated toolsets 
offer integrated functionality across a number of functions, thus simplifying the 
interfaces between them (e.g., data will automatically be consistent across 
functions). Purchase of such tools will help reduce costly customization or the 
development of add-ons. 

It is important to understand the level of integration between products, however, 
before buying them. Integration varies from vendor to vendor and can mean 
anything from simply having an icon on a desktop to fully integrated applications 
and data. In addition, integrated toolsets are likely to be stronger in some functions 
than in others, and may preclude selection of the best possible tool for every 
function. 

Anticipated Volume of Data & Transaction Throughput 

Understanding the anticipated volumes will provide key input to sizing the system. 
Predicted business volumes stated in the SLA should be used to help determine the 
appropriate sizes for machines, databases, telecommunications lines, etc. 
Alternatively, experience from previous engagements can provide useful input. 

Number of Users for the Tool 

Users may not be limited to the number of support personnel accessing a tool alone. 
Keep in mind that users of the tools may either be support personnel, vendors, users, 
senior managers, etc. 
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Some tools will only support a limited number of users, or may only support users 
within certain geographic boundaries. It is important to understand if there are any 
such limitations prior to purchasing a tool. 

In addition, the number of users will affect the budgetary requirements for the 
purchase of a tool, particularly as they relate to hardware and communications 
requirements. 

Level of Support Required 

If third party software is to be purchased, suppliers must be assessed on their ability 
to ensure the availability, reliability, performance and user support for these tools 
will be sufficient to deliver the appropriate levels of service to the users of the 
system. It may even be necessary to visit reference sites for the vendors to 
determine whether these requirements are being met. 



PRESENTATION (9302) 



The presentation component provides the interface between the manager(s) of the 
system and management data generated by the system. Data can be manipulated for 
various forms of output. By integrating the operational architecture it is possible to 
reduce the number of front-end interfaces required. Commonly, the presentation 
component uses a GUI front-end interface. This component is also responsible for 
real-time and historical report generation. 
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EVENT PROCESSING (9304) 



Event processing manipulates the raw data obtained in the event/data generation 
layer into a more workable form. This layer performs functions such as event 
filtering, alert generation, event correlation, event collection and logging, and 
automated trouble ticket generation. Event processing routes the processed 
information on to either the presentation or management applications layers. Again 
it is important to consider the interface of the event processing component with the 
other components of the operational architecture. 



Help Desk (9306) 



As with End User Services in the centralized model, the Help Desk is the single 
point of contact for all end users. This unit has end-to-end accountability for all user 
incidents and problems regardless of whether or not it has the resources to fix them 
(i.e., it must contact the necessary technical resources in either IS organizations to 
ensure the incidents and problems get resolved). 



Incident Management (9308) 

Incident Management provides the interface between the users of the system and 
those operating and maintaining the system when an incident arises. Incident 
Management is responsible for: 
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• receiving incidents from users 

• informing users of known work-around where possible 

• ensuring that support personnel are working on an incident 

• keeping users informed of incident resolution progress 

• ensuring that incidents do not get lost as they are passed around support teams 

• informing users when incidents have been resolved and ensuring resolution was 
complete. 



In addition, Incident Management is responsible for ensuring that outstanding 
incidents are resolved in a timely manner. As part of Incident Management, 
incidents are reviewed, analyzed, tracked, escalated as necessary, and resolved. 



Failure Control (9310) 



Involves the detection and correction of faults within the system whether they be 
minor (e.g., workstation is down) or major (i.e., a disaster) has occurred. 
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Fault Management (9312) 

When a negative event has been brought to the attention of the system, actions are 
undertaken within Fault Management to define, diagnose, and correct the fault. 
Although it may be possible to automate this process, human intervention may be 
required to perform at least some of these management tasks. 



EVENT / DATA GENERATION (9314) 



Event/data generation interacts with all the managed components in the execution 
and development environments in order to obtain the required management 
information. This component also interacts with the physical environment, 
managing hardware, and supporting infrastructure components of the operational 
architecture to obtain management information. It is important to consider these 
interfaces when choosing event/data generation components. Agents and proxies are 
two common types of event/data generation tools. Often these tools use 
broadcasting and trapping methods to capture information. Application generated 
events from vendor packages and user applications also fit into this component of 
the operational architecture. 
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Monitoring (9316) 

Verifies that the system is continually functioning in accordance with whatever 
service levels are defined. 



Event Management (9318) 

An event is an electronic message generated by any component (e.g., application 
software, system software, hardware, etc.) in the system. Event Management 
receives, logs, classifies and presents event messages on a console(s) based on pre- 
established filters or thresholds. 



MANAGEMENT APPLICATIONS (9320) 

Management applications are those tools which are used to manage the system. 
Most of the MODE functions tie directly into this component. The management 
applications component ties in directly with the integration platform component as 
the management applications tools must comply with the standards set by the 
integration platform. For example, if the integration platform is HP Open View, then 
the management applications must be HP OpenView software (API, SNMPx) or 
hardware (card) compliant. Management applications receive data from the 
event/data generation, event processing, and repositories components and then send 
data to the presentation or repositories components. Management applications tools 
include capacity planning tools, performance management tools, license 
management tools, remote management tools, systems monitoring tools, scheduling 
tools, help desk tools, etc.. Some Enterprise Management tools even poll the 
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event/data generators for information but these options may impact network 
performance. Web Server management is been introduced as part of the 
management operations framework. As Corporate Internets and Extranets 
implement Web based software products to sell and advertise business services, 
corresponding administrative, security, event notification and performance 
requirements must be performed similarly for the companies web based system. The 
critical path issues for Web based server software is typically security and 
performance based levels of service. 



Help Desk (9322) 

As with End User Services in the centralized model, the Help Desk is the single 
point of contact for all end users. This unit has end-to-end accountability for all user 
incidents and problems regardless of whether or not it has the resources to fix them 
(i.e., it must contact the necessary technical resources in either IS organizations to 
ensure the incidents and problems get resolved). 

Implementation Considerations 

The following are functional requirements for Incident, Request and Problem 
Management. 

Logging Incidents / Requests 

Call logger should be presented with a unique incident / request identifier, and 
should be able to enter a free format description as well as the key data items 
specified in the data requirements section. Data and time stamps should be 
automatically registered and Incident and Request management staff should have 
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access to display all open incidents and requests as well as the incident/request 
history for a specific user location. 

Progress Incidents /Requests 

Facilities should be given to provide a free format update of actions and 
investigations, to assign the incident / request to a support group, or to escalate the 
incident. Date and time stamps should be attached to each action and the full 
incident/request history should be available to the person performing the update. 

Re-assign Incidents / Requests 

Possible for incidents and requests to be assigned to different support groups, if 
further investigation is required. 

Close Incidents / Requests 

Incidents and requests should be closed with a date and time stamp to help trend 
analysis and service level reporting. 

Log Problems 

Problems can be logged both as a result of one or more incidents, or through 
proactive monitoring of the system, before any incidents have been logged. 

Support the functions either centrally or on a distributed basis 

If the Incident, Request and Problem management functions are to be centralized, 
these functions need to be able to control and monitor incidents and problems, but 
other functions should be able to gain access to input detailed technical information 
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or progress updates. If Incident and Request management is distributed, it is 
recommended that remote locations are given access to the central system, rather 
than operating local systems. (Some problem areas are local sites operating on 
different time zones and standardizing escalation procedures from local sites.) 

Facility for auto-logging incidents 

Event / alert based automatic logging of incidents to provide proactive management 
of incidents and problems by informing Incident management of issues before the 
user logs a call. This facility is conceptually desirable, but is only likely to be 
available if the Incident management functionality is part of the monitoring tool. 
The costs of building hooks between tools and applications are likely to prove 
prohibitive. In medium or large environments, this facility is extremely desirable, 
and must be built into the requirements. 

Assess incidents automatically, based on previous experience and rules 

Knowledge and case based incident management systems are becoming prevalent in 
the market place, and are built into Help Desk offerings. Use of these systems can 
help improve the responsiveness and reputation of the entire organization. (Case 
based tools will require building up over time.) 



Incident Management 

Incident Management provides the interface between the users of the system and 
those operating and maintaining the system when an incident arises. Incident 
Management is responsible for: 
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• receiving incidents from users 

• informing users of known work-around where possible 

• ensuring that support personnel are working on an incident 

• keeping users informed of incident resolution progress 

• ensuring that incidents do not get lost as they are passed around support teams 

• informing users when incidents have been resolved and ensuring resolution was 
complete. 



In addition, Incident Management is responsible for ensuring that outstanding 
incidents are resolved in a timely manner. As part of Incident Management, 
incidents are reviewed, analyzed, tracked, escalated as necessary, and resolved. 

Implementation Considerations 

Will users be given access to the Incident Management system? 

Users will benefit by gaining up to date information on the progress of incidents, and 
could be given the facility to log incidents directly, which would relieve some of the 
load of the Incident Management function. However, this adds complexity to the 
solution, and increases communications requirements / costs. 
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Which support personnel will be given access to the Incident Management system? 

Support personnel would be able to enter progress against incidents without 
contacting Incident Management. The ability to scan incidents may also aid the 
Problem Management function. However, this adds complexity to the solution, and 
may increase communications requirements / costs. 

How many incident support levels will be in place, and how expert will the Incident 
Management function be? 

This will depend on the knowledge and experience at the user locations. The level 
of technical expertise within the Incident Management function will drive the 
systems requirements. 



Problem Management 

Problem Management utilizes the skills of experts and support groups to fix and 
prevent recurring incidents by determining and fixing the underlying problems 
causing those incidents. Within Problem Management, related incidents are 
correlated to problems and ultimately to order or change requests. All problems are 
logged, tracked and archived. Where possible, work-around are determined and 
information regarding the work-around is distributed to the appropriate support 
personnel and user communities. 
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Implementation Considerations 

Will problems be automatically logged or only by manual association with an 
incident? 

Automatic logging of problems will require interfaces to be built with the Event 
5 Management system, and perhaps the execution architecture for application errors. 



C3 
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Request Management 



C3: Request Management is responsible for coordinating and controlling all activities 

necessary to fulfill a request from either a user, vendor, or developer. Request 
10 Management determines if and when requests will be fulfilled through interaction 



f U; with the particular fimction(s) impacted by the request. Following such interaction, 

pi]* accepted requests will be planned, executed, and tracked. 



Implementation Considerations 

15 Will users be given access to the Request Management system? 

Users will benefit by gaining up to date information on the progress of incidents, and 
could be given the facility to log incidents directly, which would relieve some of the 
load of the Incident Management function. However, this adds complexity to the 
solution, and increases communications requirements / costs. 
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Failure Control (9324) 



Involves the detection and correction of faults within the system whether they be 
minor (e.g., workstation is down) or major (i.e., a disaster) has occurred. 



Fault Management 



When a negative event has been brought to the attention of the system, actions are 
undertaken within Fault Management to define, diagnose, and correct the fault. 
Although it may be possible to automate this process, human intervention may be 
required to perform at least some of these management tasks. 



Disaster Recovery 

In the event of a significant system failure, Disaster Recovery processes will be 
invoked to re-route the system resources to a secondary, stable configuration until 
the primary resources can be restored. Within a distributed environment, disaster 
recovery must account for differing levels of disaster whether at a central or 
distributed site(s). 
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Implementation Considerations 

What is a disaster? 

The way in which a disaster is defined will be dependent upon which resources are 
critical to the business. For example, a data center failure may be critical for one 
client whereas a server failure for another is more critical. 

How quickly will disaster recovery be required for each service? 

This will be defined in detail within the SLA, but high level service recovery targets 
must be understood, so that high level recovery plans can, in turn, be produced. 



Recovery 

Recovery manages all of the actions needed to restore service delivery after a system 
failure. With critical business applications being rolled out on distributed 
technologies, the recovery of these systems must be easy, quick and efficient to 
guarantee availability of core business systems as expressed in the agreed service 
levels and operational levels. 

Implementation Considerations 

What are some of the limitations that are encountered? 

Recovery capabilities span the range from those required to bring up a device after it 
has failed to those required in the event of a major disaster. With critical business 
applications being rolled out on distributed technologies, the recovery of these 
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systems must be easy, quick and efficient. Loss of the system for even a short 
period of time can result in significant financial losses to a clients business. 
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Hardware Maintenance 

Hardware Maintenance maintains all of the components within a distributed system 
to protect the investment of the organization. Generally agreed upon in the SLAs, 
maintenance contracts are carried out, monitored and recorded for each asset as 



10 Administration (9326) 



Billing and Accounting 



Billing & Accounting gathers the necessary accounting information for calculating 
actual costs, determines chargeback costs based on pre-defined algorithms and bills 
15 users for service rendered. 



Billing & Accounting also makes payments to service providers for services and 
equipment provided in accordance with agreed upon SLAs. As part of this payment 
process Billing & Accounting reconciles bills from service providers against 
20 monitored costs and SLA/OLA violations. 
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Systems Management Planning (9330) 
Capacity Modeling and Planning 

Capacity Modeling & Planning ensures that adequate resources will be in place to 
meet the SLA requirements, keeping in mind operational requirements which may 
require additional capacity. Resources can include such things as physical facilities, 
computers, memory/disk space, communications lines and personnel. Through this 
component, changes to the existing environment will be determined, modeled and 
planned according to the necessary requirements. 



Production Control (9332) 

Ensures that production activities are performed and controlled as required and as 
intended. 



Production Scheduling 

Production Scheduling determines the requirements for the execution of scheduled 
jobs across a distributed environment. A production schedule is then planned to 
meet these requirements, taking into consideration other processes occurring 
throughout the distributed environment (e.g., software and data distribution, remote 
backup/restoration of data.) It plans the production workload and then submits the 



-331 - 



tasks to the system in the proper sequence, stops processing upon detecting a failure, 
provides on-line task tracking and workload forecasting. 

Implementation Considerations 

In a distributed environment are processes across entire or multiple platforms and 
systems? 

Processes may be taking place across the entire system on multiple platforms in 
either a parallel or a serial fashion. Batch dependencies may be required across 
platforms, and multiple time zones may be involved. In addition, many non- 
mainframe based products do not provide production scheduling capabilities with 
the platform. Therefore, one can see that scheduling processes across a distributed 
environment can be quite complex, requiring significant management effort to 
ensure that processes occur appropriately. 

How many schedulers will be used to control the schedules? 

• Depending on how the function is to be controlled, and how many platforms are 
to be supported: 

• Local control of a single device with a single scheduler (typically mainframe) 

• Remote control of a single device with a single scheduler 

• Remote control of multiple but independent devices with a single scheduler 
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Product Considerations 

What is the Intended use of the tool? 

The component plans for the production workload and then submits the tasks to the 
system in the proper sequence, stops processing upon detecting a failure, provides 
on-line task tracking and workload forecasting. In addition, requirements are 
determined for the execution of scheduled jobs across the environment. 

Does and existing component satisfy this requirement? 

Production Scheduling contains specific requirements that addresses a distributed 
environments complexity of multiple platforms and system placed in either a parallel 
or serial fashion. 

What other utilities are available with the tool? 

The tool should provide control dependencies to schedule workloads such as: 
Task/job sequence enforcement, external/internal event driven. Graphically displays 
work flow from the scheduling criteria and includes such information as task/job 
name, task description, average run time and resource requirements. Allow clients 
to define user schedules that can be based on predecessor events in the production 
environment. Reporting capabilities for forecasting, simulation and analyzing 
scheduled workload. Monitoring capability of past, present and future workloads as 
well as tracking of current workload termination notification of normal or abnormal 
completion. 
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Does the development team have any prior experience with the tool? 

The development should be able to identify the component linkages as well as the 
functional requirements critical for successful operational integration of the tool into 
the observed environment. 

What level of the component is required? 

Due to the complexity of a distributed environment one must account for the 
processes taking place across the entire system on multiple platforms in either a 
parallel or a serial fashion. Therefore, production scheduling capabilities across 
platforms is critical as well as the ability to rerun / restart from single point of failure 
or provide checkpoint restart- ability. 

Does the tool provide facilities to add color to MODE architecture model? 

• Communication with Performance management component to forecast resource 
requirements, such as near line storage, DASD space, and etc.. 

• Interface with the Configuration management component facility to obtain 
. configuration data in workload forecasting. 

• The scheduler will communicate with other schedulers on other systems to run a 
in a close relationship with the ability to support multiple heterogeneous 
platforms: MVS, Windows NT, UNIX, and AS/400. 



Communicates with Backup / Restore to identify scheduling constraints due to 
backup and restoration functions. 
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• Communicates with the recovery facility to dynamically switch workload from 
one processor to another in the event of a system failure. 



Print Management 

Print Management monitors all of the printing done across a distributed environment 
and is responsible for managing the printers and printing at both central and remote 
locations. The purpose of a print architecture is to make formats applications 
independent, so that the only thing applications need to do is obtain the data. 



Print Architecture offers: 

• It provides independence from printer devices and languages 

• It makes it easy to develop and maintain report 

• Paper consumption may be reduced 

• Reports arrive to the addressee more quickly 

• It is possible to sign reports electronically 

• Confidentiality is improved as people can only see information that can be 
accessed with their security level. 
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Implementation Considerations 

What types of printers will be required (e.g., laser, impact, inkjets, etc.)? 

The types of printers will be dictated by the business requirements. The types of 
printers, will in turn, determine what tools can be used to manage printing may or 
may not be required. 

Where are the printers going to be located? 

The business will help determine where the printers need to be located based on 
where/ when printing needs to take place. In some instances local printing may or 
may not be required. 

What spooling facilities will be available? 

If spooling is available, printing can be handled as a background task, freeing up 
system resources for use on-line. 

Will review before print facilities be provided? 

If these facilities will be provided, all material will not need to be printed. If the 
material does need to be print; however, the location of the printing must be 
determined, and the system must be able to forward the printing on to the 
appropriate location. 

Will printing of large documents be necessary? 

Large print jobs may utilize system resources considerably (e.g., WAN, LAN, 
printer), and may tie up the printing queue for other individuals. This type of 
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printing should be performed in off-hours or delayed to avoid contention for the 
printer during business hours. 

What are some limitations that may be encountered? 

In a distributed environment the sizing and routing of print traffic is more complex. 
With new systems being installed, only educated guesses about how and when 
printing will take place can help determine print routing functionality. In most 
cases, some adjustments will be required to the print routing algorithms post-rollout 
to reflect the printing reality. 

Product Considerations 

What is the intended use of the tool? 

Controls report production and distribution form the moment the report is created to 
the time the printed report is dropped in the end-use s mailbox (electronic, paper, 
microfiche, etc.) 

What other utilities are available with the tool? 

• Provide queue management and ability to prioritize. 

• Provides a full featured on-line viewing system. 

• Provides for the archival of reports in a compressed format first on disk, for a 
user specified time and then to tape of optical. 

• Process reports in due-out-sequence. 
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• Automatic report balancing and archives the balancing reports for easy auditor 
review. 

• Provides a common output spooling and printer device control capability across 
the network. 

5 • Provide report reprint capability, avoid reruns in lost report situations. 

• Provide centralized management of report setup and delivery information 
How well does the tool integrate with other tools in the environment? 

• Interfaces with the performance monitoring to identify bottlenecks in the 
distribution process 

10 • Notifies the service level management facility of any missed service 
commitments. 

• Communicates with the documentation management facility to obtain the 
distribution information, media type and service level commitments. 

• Communicates with the recovery management facility to delete reports that will 
1 5 be recreated. 

• Communicates report volumes to the resource consumption management facility. 
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Does the tool provide support for specific areas? 



Support multiple printer types as well as report delivery across them. This includes 
printer format translation (PCL, Postscript, etc..) and code translation. 

Any other specific functional requirements? 

Output management issues require leverage of existing print capability, local and 
remote printing, and distribution management through a software package or an 
equivalent alternative. 



File Transfer & Control 

File Transfer and Control initiates and monitors files being transferred throughout 
the system as part of the business processing (e.g., nightly batch runs). File transfers 
may occur between any two or more devises within the system. 



System Startup & Shutdown 

System Startup and Shutdown performs the activities required for the startup or 
shutdown of the entire system (e.g., hardware, applications), or portions of the 
system depending upon the identified requirements. Within a distributed 
environment, the system includes both centralized and remote resources. 
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Implementation Considerations 

Will devices need to be shutdown /started remotely as well as be automatic or 
manual (e.g., using scripts, embedded in schedule)? 

If expertise will not be available locally, it is imperative that remote control of the 
startup / shutdown processes be available. The presence of skills, the availability of 
tools, and the uniqueness of the application / environment will dictate whether or not 
startup / shutdown is automatic or manual. 

How will clean shutdowns of all processes be ensured? 

If a system failure takes place, it is important that all processes be shut down well, to 
ensure that the processes can be re-started and that the integrity of the information 
will be maintained. 

In what order will hardware and software components be started / shutdown? 

Based upon the technical requirements of the system (e.g., databases should be 
started before applications) as well as defined service levels (e.g., one particular 
application is critical and must be started first), the order of startup / shutdown will 
be determined. 

Are periodic re-boots required (e.g., to clean up memory)? 

If this is necessary, automatic/manual startup/shutdown of the system should be 
scheduled (e.g., UNIX systems require this). 



-340- 

Analysis of the system and other resources need to be addressed? 

The state of an application, the system or a specific resource must be known at all 
times. Common activities performed as part of Startup / Shutdown include: 

• logging on 

5 • virus checking 

• version checking 

• process initiation / completion 

• housekeeping 

• logging off. 

Some limitations that may need to be taken into account? 

System startup and shutdown is no longer confined to a centralized site. The system 
is distributed, in effect creating islands of technology which may be started or 
shutdown with the flip of a power switch on a workstation. Processes which rely on 
the system being up and running (e.g., software and data distribution) may fail if a 
15 user has switched his/her machine off before leaving for the evening. Such failures 
will impact the following days processing capabilities and must be accounted for 
either by the system or through training. In addition, controlled machine startup 
may be required to initiate tasks or to perform activities such as configuration 
checking or virus detection/correction. 
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Mass Storaee Management 

Mass Storage Management involves those activities related to the handling of 
various types of centralized and distributed storage media including the monitoring 
and controlling of storage resources and their usage. 



The objectives of Mass Storage management are to: implement the top level of 
storage management, control the usage level of each storage device in the distributed 
environment, control all storage related naming standards and placement details in 
the installation. 



Mass Storage Management is more complex in a distributed environment than in a 
centralized environment since many more storage options become available, as 
storage may take place centrally or on a distributed basis and the number and 
characteristics of storage devices have increased. 

Implementation Considerations 

What DBMS will be used and what utilities does it have? 

The DBMS will often provide much of the necessary storage management 
functionality; this decision impacts further requirements. 
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Will databases be distributed or centralized? 

Storage management for centralized databases will clearly be simpler then for 
distributed databases were a global view becomes more difficult to obtain, and 
where data consistency becomes more of an issue. 

What media types will be used? 

It is essential that the types of device to be used are understood before detailed 
decisions are taken. 

Distributed Environmental Constraints? 

The allocation and sharing of storage media is more difficult to plan since users are 
distributed. Mass Storage Management is more complex in a distributed 
environment as many more storage options become available; storage may take 
place on disks, tapes, etc. Either centrally or de-centrally. 

Product Considerations 

What is the Intended use of the tool? 



Control and manage the data storage environment including any/all media, disk, 
optical and tape. 
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Technology's ability to support the Operating Systems within the distributed 
environment? 

The tool must run in the platform selected in order to control usage of disk space, 
main memory, cache, etc. In addition, determining the space available helps control 
the device usage, storage capacity 

What other utilities are available with the tool? 

• Continuous analysis of the data storage environment to insure optimum storage 
utilization and location. 

• Eliminate fragmentation by reordering files 

• All storage devices managed independently of their type and location in order to 
avoid storage problems, bottlenecks, etc. 

Should the tool provide specific component functionality ? 

The tool should take into account the complexity of the distributed environment as 
well as the flexibility of the scenario that storage may take place centrally or on a 
distributed basis and the number and characteristics of storage devices have 
increased. 

Does the tool provide support for the databases selected for the distributed 
environment? 

Additional facilities may be required, even although databases typically have built-in 
utilities or tools to perform these function and do not generally require a separate 
tool. 
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Does the tool provide facilities to add color and support linkages to MODE 
architecture model? 

• Communicates with the Performance management facility to identify any 
performance problems and relocate data based on the performance analysis. 

• Communicates with operation system error logging and/or the Operations 
Automation to identify any potential media or hardware failures and relocate 
data, automatically files a problem log for corrective action. 

• Interface with the Capacity / Resource manager to create a definable resource 
forecast. 



Backup / Restore Management 

Backup and Restore Management considers all of the back-up and restorations that 
need to take place across the distributed system for master copies of data. 
Depending on the need, these processes may occur centrally or remotely. 

Implementation Considerations 

What data /files will be backed up? 

Files that are either unique, store site specific data or are highly volatile should be 
backed up. This will help ensure that important, business critical data will not be 
lost in the event of a system failure or disaster. All files do not necessarily need to 
be backed up as each file backup utilizes storage space and ma impede the 
performance of the system 
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What will be the frequency of the backup, the number of copies made, and the 
number of generations maintained? 

The critically and volatility of the information will determine the frequency of the 
backups and whether or not multiple copies of the data are maintained centrally / 
locally. In addition the stability of the system needs to be considered as well as any 
performance impacts of backing up the data as required. 



The number of generations maintained will be dependent on the disaster recovery 
policies in place as well as any government / regulatory controls in existence. 

How will the integrity of a backup or restore be ensured? 

Because databases can be located throughout the distributed environment, care must 
be taken to ensure that data integrity is maintained. This may mean storing the 
master copy of data centrally, or synchronizing the commits of updates of the 
information appropriately. 

Will the data be backed up centrally, locally, or at an alternate site? 

Centrally located devices will require the use of both LAN and WAN bandwidth to 
backup the data, and restoration of the data will be slower. This may be hard to 
achieve if there are numerous devices in the system. Central location, however, will 
ensure that backed up data will be stored in one place, potentially making recovery 
from a system failure or disaster recovery easier as well as centrally less expensive 
to maintain. In addition, central control over the backup / restore process will 
require expertise at a single location whereas local control will necessitate expertise 
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in multiple locations. Alternate site control may provide the best mix of central / 
local placement of skills. 

In contrast, local devices do not utilize the WAN bandwidth, and typically provide 
faster data restoration. Local devices, if available, may be more expensive and may 
require local expertise. 

Alternate site backup combines both of the strategies in that WAN bandwidth to the 
central site is not over-utilized, and restoration of the data can happen fairly quickly 
as well as securing information as information is stored in multiple locations. 

Will copies be held at multiple locations? 

Backup copies may need to be stored at multiple locations for security purposes (i.e. 
in the event of a system failure, or disaster, some backup copies may have been 
destroyed.) 

Product Considerations 

What is the intended use of the tool? 

Provide services and facilities to enable the client to effect timely and accurate 
recovery in the event of an interruption to processing capability. 

What other utilities are available with the tool? 

• The backup product should have fundamental management capabilities. 

Automatic restore, unattended operation and command line processing of the 
product should be available. Basic tape functions such as cataloging, internal 
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labeling, initialization, certification, scratch protection and write protection are 
musts. 

• Performs automatic backup of data files on site standards. 

• Designed along the lines requester-server model; more specifically the tool runs 
on the server machine and acts as a shared resource for data access, integrity, 
security recovery, etc.. 

• Full auditing capability should be present for backups as well as error detection 
and notification that a backup has failed should be available. 

• Provide full and incremental backups, partial restore, and compression / 
decompression. 

• Capable of managed and systematic restore process. 

How well does the tool integrate with other tools in the environment? 

Backups are typically embedded into production scheduling with restores on an ad 
hoc basis. Backup / Restore needs to ensure that a file can be only backed up / 
restored by users with the right access level. Furthermore, file transfer utilities need 
to be used when the information to archived is sent through the network as well as 
security for file control access and global authorization should be available and done 
in concert with the security management facility. 
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Should the tool provide specific component functionality? 

Database backup / restore is inherently more complex than backup of standard files. 
It is important to ensure that all relationships are resurrected after restoring database 
files. (Integrated with the functionality of the DBMS) 

Does the tool provide support to specific areas? 

• The product should support multiple heterogeneous platforms: Windows NT, 
AS / 400, MVS and UNIX. 

• Software features of the product should support items such as direct file access, 
direct volume access and extended attributes. The ability to backup the 
operating system files. Support should also handle open file backups either 
waiting and retrying or taking a fuzzy backup. 

• Dual logging support in the DBMS is required, both for online and archived 
logs. 

• Pint in time recovery of database and database components must be supported. 

• Ability to support various types of storage devices (magnetic disc, cartridge, 
tape, optical disc.) 

Does the tool provide support for a specific environment? 

The ability to support unattended operations reduces the need for operations 
expertise in both central and remote locations 
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Does the tool add color to MODE architecture model through performance 
measures? 

Performance of the backup product is essential. The tool should backup all 
production data in the processing window provided and the restore capability should 
match availability and disaster recovery requirements. Performance can be 
enhanced through the ability to throttle the backup process to reduce network traffic. 



Archiving 

Archiving saves and stores information across the distributed environment, either 
centrally or in distributed locations. Archiving moves datasets, files, etc. from one 
device to another, usually lower speed, device based on a number of parameters. 
Archiving can be used to move information to or from distributed and centralized 
sites. 

Implementation Considerations 

Which files and databases will be archived? 

Some files and databases need to be stored on fast devices so users can access them 
quickly. In addition, certain files may need to be maintained for either historic or 
government / regulatory reasons. 




-350- 



What media will be used for archiving? 

The cost of the media, space available and its performance capabilities should 
determine which archiving medium is used as well as the existence of central or 
local expertise. 

How long should archived data be maintained? 

It is important to define the maximum time that data needs to be stored before being 
deleted, including the number of generations that need to be maintained. This is 
because the amount of archival space should be determined up front. The maximum 
time will likely be determined by either government / regulatory controls or disaster 
recovery requirements. 

How will the integrity of retrieved data or files be ensured? 

Because databases can be located throughout the distributed environment, care must 
be taken to ensure that data integrity is maintained. This may mean storing the 
master copy of data centrally, or synchronizing the commits or updated of the 
information appropriately. 

Will archiving devices reside centrally or locally? 

Central control over the archiving process will require expertise at a single location 
whereas local control will necessitate expertise in multiple locations. 

Centrally located devices will require the use of both LAN and WAN bandwidth to 
archive the data, and retrieval of the data will be slower. This may be difficult to 
achieve if there are numerous devices in the system. Central location, however, will 
ensure that archived data will be stored in one place, potentially making recovery 
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from a system failure or disaster recovery easier. In addition, central devices may be 
less expensive to maintain. 



In contrast, local devices do not utilize the WAN bandwidth, and typically provide 
faster data retrieval. Local devices, if available, may be more expensive, and may 
require local expertise. 



Implementing (9334) 

Executes change within the distributed environment with tested components and 
techniques according to the appropriate plan(s). Implementing includes such things 
as: initial installation, software & data distribution, license management, etc. 



System Component Configuration 

System Component Configuration provides a mechanism to configure equipment 
(i.e., hardware and software) which has configuration parameters to set and to 
manage the inter-relationships between configured components within the system. 
Configuration information for particular equipment must be coordinated across the 
system to ensure that all equipment can function together properly. 
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Implementation Considerations 

Where does the function get input from? 

Configuration settings can be retrieved from different sources. The release and the 
rollout schedule will contain a detailed description of equipment and its 
configuration and can therefore be used as input. Alternatively, the asset inventory 
system can be updated in advance and then used as an active database to drive the 
configuring process. 

Product Considerations 

What is the Intended use of the tool? 

Definition and implementation of consistent configurations for all configurable 
components within the system. 

What other utilities are available with the tool? 

• Hardware and Software should be configured accurately and with minimal 
business disruption during initial installation. 

• Ability to re-configure hardware and software both locally and remotely. 

How well does the tool integrate with other tools in the environment? 

The asset data has to be updated accordingly and must reflect the actual state of 
hardware and software and all their relationships. Configuration data may be 
distributed to the device by Software & Data Distribution; therefore, System 
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Component Configuration needs to get access to Software & Data Distribution 
processes. 



Software & Data Distribution 

Software and Data Distribution sends out the correct version of the release package 
to the distribution locations and updates the locations with the contents of the release 
package (e.g., software, data, configuration information, procedures and 
training/support materials.) 

The software and data distribution mechanism itself updates either the software, 
data, or configuration information on a machine(s), reports the relative 
success/failure of the distribution and updates the asset information for the 
sites/machine(s) affected by the distribution. 

Implementation Considerations 

What are some limitations that may be encountered? 

Training Planning also impacts how well service will be delivered within the 
distributed environment. The skill sets required by support personnel will change 
with the introduction of distributed technologies. Support personnel will be required 
to have greater breadth of knowledge. No longer can an individual simply 
understand the network or the applications. The intertwined nature of a distributed 
environment will force individuals to understand, at least at a high-level, how the 
system fits together. In addition, support personnel will need to have some 
specialized skills. As no one individual can fully understand the detail behind the 
entire system, teams of specialized support personnel will be required to work 
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together to a greater extent in these environments. This group interaction may 
require new skill sets not frequently found in traditional support organizations. 

What are some focus areas to determine an appropriate training plan? 

The existing skills must be assessed and a forward-thinking training direction must 
be defined. The training plan will likely emphasize newer technologies and different 
methods of training with the underlying goal of providing the appropriate level of 
service as required by the SLAs. 

Product Considerations 

What is the intended use of the tool? 

Support the ability to distribute software components to interdependent, multiple 
heterogeneous platforms from a single source. The features should be automated 
and only require minimal operator involvement. 

What other utilities are available with the tool? 

• Centralized control and administration of distribution function. 

• Backout, configuration restoration capability. 

• Schedulable, unattended distribution and installation of software. 

• Ability to generate distribution candidate lists from asset / inventory 
management database. 
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• Logging of status / failures to centralized system monitoring facility. 

• Ability to distribute release packages constructed in module control / versioning 
facility. 

• Pre-defined installation and de-installation scripts. 

• Ability to perform complete back-out of all related segments quickly and 
automatically, without impacting other, successfully installed updates. 

• Features should include: data compression and decompression, check-pointing, 
and retry. 

• Users should be allowed to postpone distribution to their workstation. 
What level of the component is required? 

• The function must be able to access a release library, to identify release 
packages, release component groups and release components, and to associate 
the correct version number with these components. 

• Ability to select destination nodes by certain criteria, such as location, hardware 
type, standard configuration at these nodes and to address these nodes in the 
network. 



• The function must send to and install software and data at remote locations 
reliably and within an agreed time scale causing minimum disruption. 
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• The function must be able to back out remotely, either as part of the distribution 
or as a separate process. The mechanism must be able to regress to the previous 
operable state prior to disruption. 

• Ability to synchronize data and time between systems. 

How well does the tool integrate with other tools in the environment? 

Software & Data Distribution needs to access and update asset data in the asset 
inventory system to reflect implemented changes (automatically). In addition the 
function may be based on the same file transfer protocol as File Transfer & Control; 
unless the tools uses their own proprietary file transfer method based on a standard 
communication protocol. 

Does the tool provide support for specific environments? 

Specialized functionality to support operation across the wide-area network 
environment including: parallel distribution and data compression. In addition, 
support of platform specific functions and capabilities due to awareness of platform 
specific information resident in the asset / inventory database. 



User Administration 

User Administration handles the day-to-day tasks involved in administering users on 
the system. These tasks include such things as: adding new users, changing user Ids, 
re-establishing user passwords, maintaining groups of users, etc. 
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Security Management 

Security Management controls both physical and logical security for the distributed 
system. Due to the nature of a distributed environment, security may need to be 
managed either centrally, remotely or through a combination of the two methods. 

Security Management also handles the logging of proper and illegal access, provides 
a way to audit security information, rectify security breaches and address 
unauthorized use of the system. 

Implementation Considerations 

Some limitations that may be encountered? 

Security must exist in various levels throughout the system in order to prevent 
unauthorized access. Security components must be packaged into a security 
architecture which can be effectively managed by an organization through their 
security management strategies. The Kerberos security approach within 
client/server architecture, for example, utilizes interconnected security servers and 
distributed security clients to provide security for the distributed environment. 

The number of security components required to secure a distributed environment 
will increase due to the computing power available through the use of these new 
technologies and the heterogeneity of the environment. Although things such as 
dial-up access, LAN access, multiple host access, etc. introduce new user 
capabilities, they simultaneously introduce security risks into the system. 
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What are the benefits of single logon capabilities? 

Due to the number of components, users may be required to have multiple ID(s) and 
passwords unless the system is designed to allow a user to access all of the required 
resources through a single logon. As most products on the market typically allow 
5 access to only a subset of resources, single logons with multiple ID and password 
coordination may be difficult to achieve. Issues such as periodic required password 
changes can be difficult to overcome while maintaining adequate security. 

Product Considerations 

What is the Intended use of the tool? 

Protects all computer resources, facilities and data from accidental or intentional 
destruction, modification, disclosure and / or misuse. 

What other utilities are available with the tool? 

• One User-ID for access to all software (central point for all security checking). 

• Maintains a security log and user profile of what was accessed when, from a 
15 computer resource, facility and data view point. 

• Security Administration ability to monitor the activity of a user of resource. 

• Allows users capability, when authorized, to maintain their own security profiles 
by individual or group. 



20 



Access authority for database objects (data-sets) as they appear outside the 
DBMS must be controlled. 
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• Database authorities must be manageable at a group / role level. 

• Single user setup and sign-on capability across all platforms and applications. 

• Virus protection on all platforms. 

• Support for external security devices and dial access equipment, etc.. 

• Encrypted flow of security information across the network. 

• Comprehensive access logging and auditing capability. 

• Enhanced security capability beyond normally supplied UNIX levels. This 
includes being able to support scoped UNIX administrative users (root subsets, 
limited root functionality). 

Network Management 

Network & Systems Management Planning is responsible for the planning activities 
involved in running the day-to-day operations and maintenance of the production 
systems (e.g., capacity planning, performance planning, etc.). 
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Controlling (9336) 

Monitors change to make sure that change is delivered on-time according to 
established plans, making adjustments to the plan when unforeseen issues or events 
5 arise (e.g., rollout management, change control, asset management etc.) 



Change Control 

Change Control is responsible for coordinating and controlling all change 
administration activities within the distributed environment (i.e., document, impact, 
authorize, schedule, implementation control.) 

Implementation Considerations 

What types of changes will be controlled by Change Control and what is the 
anticipated volume of changes? 

The types of changes Change Control should cope with need to be defined. Changes 
15 can range from a minor document change to the introduction of a complete new 

service. However, moving a workstation from one desk to another may not require a 
change request. 

Design of the function heavily depends on its size. It may be a relatively small 
environment with little expected change, or it could be a huge distributed system 
20 with many locations, many users and many different platforms. 
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It is easy to underestimate the volume and complexity of changes in a distributed 
environment. Changes to different platforms can easily become very complex. 
Experiences from previous engagements should be used to help predict figures. In a 
typical distributed environment, several hundred changes per month can be 
expected. 

To what extent should Change Control be integrated with the asset inventory system, 
maintained by Asset Management? 

Impact analysis can use Asset Management to get a detailed list of assets which are 
dependent on the subject to be changed. It may be a mandatory requirement to 
provide this list before a change request can be accepted. 

To what extent should Change Control be integrated with Incident and Problem 
Management? 

Change requests might be closely tied to incidents and problems, thus when a 
change is implemented, the corresponding incidents and problems can be cleared. 

Which media will be used for change request submission? 

Pure electronic forms will be easy to forward over different locations, but it is more 
difficult to include a signature feature for authorization, and it is not easy to attach 
documents to provide additional information. 

Therefore, further paper forms are typically used for raising change requests but the 
change administrator then stores the most important information in a change request 
database. The decision will depend primarily on the size of the system. 
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There are some limitations that may be encountered within a distributed 
environment. 

There will be multiple change drivers including the users, developers/architects and 
vendors; The change these groups will wish to introduce must be coordinated on a 
wide-scale basis as the impact of change within these environments is great. Change 
Control allows the impact of the change to be assessed along with its merits, 
timescales, etc. It also provides a way of evaluating and rationalizing multiple 
change requests against one another to determine what changes should actually take 
place. 

Product Considerations 

What is the intended use of the tool? 

Integrated central repository of source, change and configuration data used to pro- 
actively manage all events impacting user service. Manage the process of change 
activity, while maintaining the integrity of both application development and the 
production environment. Support change control from the initiation of the change, 
through production configuration across multiple platforms. 

What other utilities are available with the tool? 

• Change requests need to be registered in the system, with a unique number 
assigned as well as related incidents and problems. 

• The system must support update of change requests. Updates may include 
changing priorities, results of the assessment, and adding a summary of the 
implementation. 
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• Once a change has been implemented the change administrator must complete 
the log by closing the change request. 

• Centralized repository for software releases, including current and back-level 
generations. 



Asset Management ensures that all assets are registered within the inventory system 
and that detailed information for registered assets is updated and validated 
throughout the assets lifetime. This information will be required for such activities 
10 as managing service levels, managing change, assisting in incident and problem 
resolution and providing necessary financial information to the organization. 



What data will be stored? 

There are four options to consider, when designing the scope of the Asset 
15 Management function. Usage of the Asset inventory only as a production system 
database (core database), including hardware devices, software versions loaded in 
the production environment, their licenses and network configuration data. Thus the 
asset inventory system only stores the core systems components in the production 
environment. 



5 



Asset Management 
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Implementation Considerations 
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In addition to the production system data as describes above, it contains any existing 
release and release components such as software modules, documents and 
procedures. It also contains service level agreements and actual figures for user 
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groups and devices, incidents, problems and change requests. It may also contain 
additional data such as performance data or log of all backups taken. 

How will data be kept up-to-date? 

This can be achieved by regular and ad hoc audits, using manual and automated 
procedures. An alternative approach would be to use asset data to drive Software & 
Data Distribution. The Software & Data Distribution processes would get data from 
the asset inventory system as input If these processes configured the devices 
according to the asset inventory it would be up-to-date by definition. 

What phases of an assets life cycle should be covered by Asset Management? 

It may be appropriate to control assets within the first stage of the life cycle(i.e., 
from development on) or it my prove more appropriate to implement Asset 
Management only from the point of delivery. 

Product Considerations 

What is the intended use of the tool? 

Maintain a central repository for all software licenses and assets. 
What other utilities are available with the tool? 

• Software asset tracking by location / server, automatic detection of correct level 
of software. 



• Authorize license use. 
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• Perform periodic searches for unlicensed software. 

• Central inventory system 

• Ability to back up and archive the asset inventory system 

What are some of the inventory maintenance issues that need to be addressed? 

Ability to maintain a data model representing the basis for an asset inventory system 
that reflects the types of assets to be managed and their relationships. The model 
should be flexible to cope with future structural changes. A record needs to be 
added to the inventory system when an asset is purchased or created, or when 
changes to the environment are performed. 

How well does the tool integrate with other tools in the environment? 
Asset data needed to support various other management functions such as: 

• Hardware Maintenance 

• Release Testing 

• Procurement 

• Initial Installation 

• System Component Configuration 

• Software & Data Distribution. 
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Does the tool provide support for a specific environment? 

Current asset data from the distributed environment needs to be retrieved frequently 
through regular and ad hoc audits. 



Rollout Management 

Rollout Management is concerned with delivering new sites or services to existing 
sites on-time based on the rollout schedule. Rollout Management monitors the 
rollout progress of all functions against the rollout schedule to ensure that the 
schedule is maintained. Review of the rollout schedule takes place regularly to 
determine how well rollout is progressing and to make any adjustments to the rollout 
schedule based upon any problems or issues which arise. 

Implementation Considerations 

What are some principles that should be applied in determining rollout planning? 

At the beginning of a rollout, the number of incidents can be dramatic. This happens 
due to initial problems with hardware and system software as well as the 
unfamiliarity of the users. In addition to an increased support load, support teams 
will need more time to process an incident and to solve an underling problem since 
they will need to become familiar with the new service. Once support teams have 
become familiar with the system and know how to resolve the most common 
problems, rollout can be accelerated. 

Since many problems will occur initially during rollout, it is important to have quick 
access to support teams and development teams. If sites are close, support personnel 
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can get to the sites quickly. Once the system is more stable, remote installation can 
occur. 

Instead of planning a tight schedule that keeps teams busy all the time, some 
windows should be left in the schedule to allow catching up time in case of delays. 
Otherwise, small deviations to the schedule cannot be handled and larger delays to 
the entire schedule will result. 

When rollout continues over a period of time, hardware and system software updates 
will affect the initial implementation of the system. The service to be implemented 
itself may also be updated during rollout. Therefore it is important to review 
hardware and software maintenance and release plans and to reflect these plans in 
the rollout schedule. 

Will the system be rolled out in one big bang or through a phased rollout over a 
longer period of time? 

Rollout of a new service can either be performed at one specific point in time for all 
locations or phased over a certain period of time. Phased rollout is the preferred 
approach because it limits the risk of serious business disruptions. In some cases, 
however, it may be necessary to complete rollout simultaneously for business 
reasons. 

What are some of the limitations encountered in a distributed environment? 

Rollout Planning handles the greatest period of change in distributed systems 
management - system rollout and installation. During rollout every site and every 
user may be impacted by the changes taking place. Since delivery of the system will 
affect how well it is received by the users and is oftentimes defined by an SLA(s), 
delivery of the system must take place smoothly with minimal interruption to the 
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users. This can be challenging when both old and new architecture domains must 
exist concurrently until the rollout has been completed. 



Interdependences within the schedule must be identified prior to rollout to highlight 
the importance of the schedule and the effort required from each group involved. 



Release Control 

Release Control is concerned with delivering a release on-time based upon the 
release schedule. Release Control monitors the release progress of all activities 
against the schedule to ensure that the schedule is maintained. Review of the release 
schedule takes place regularly to determine how well the release is progressing and 
to make any adjustments to the release schedule based upon any issues or problems 
which arise. 

Implementation Considerations 

What will be the versioning strategy? 

It is necessary to determine how a release will be named and versioned. The 
following points should be considered when defining a versioning strategy. The 
versioning strategy should be kept simple and meaningful. Versions should be 
applied not only for complete releases, but for all logical groups of release 
components as defined in the release definition data model. Asset Management 
needs to reflect the release component data model in order to be able to store the 
asset information. In addition, the versioning strategy will affect Software & Data 
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Distribution to ensure that the appropriate version of software/data is resident on the 
unit prior to implementing the new release, and co-requisite checking ensures that 
implementations of software/data will leave a machine in a valid state. 

How frequently should new releases be packaged? 

5 A minimum time interval between two regular releases needs to be defined. Most 
planned releases typically occur within three to six months of one another. 

Will delta releases be allowed? 

The need for delta releases as part of the overall policy must be determined. Delta 
releases are high risk, as they require a much better understanding of what is already 
implemented. 

Delta releases have the advantage of requiring less storage space on the target 
machine but it may be more difficult to ensure that the base components are 
compatible. This can become a particular problem when many components have 
changed and several delta releases have accumulated. 

15 Will simultaneous changes across platforms be required? 

Implementing releases in a distributed environment requires complex 
synchronization across machines and platforms. An appropriate strategy needs to be 
determined. 

What are some limitations that may be encountered at distributed sites? 



20 



Release Planning coordinates the release of updates (e.g., software, data, procedures, 
etc.) to the distributed sites. An application, for instance, can no longer be delivered 
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upon successful completion of its system test. This is due to the fact that any change 
in the distributed environment will impact other components in the distributed 
environment. Releases must therefore be planned carefully to ensure that a change 
will not negatively impact the distributed system. 

5 Product Considerations 

What is the intended use of the tool? 

Monitoring and delivery of releases as well as review of release schedule versus 
planned schedule. 



10 • Provide management of source code, objects, executables, graphics, and 



What other utilities are available with the tool? 




• Track and manage multiple versions of an application, such as development, 
staging, certification, production, and prior versions of production. 



documentation. 



15 



• Provide automatic file versioning, configuration versioning, release control, 
change tracking, etc. 



Populate multiple platforms with the correct code at the same time or on 
schedule, and provide update status. 



Confirmation of release scheduling and determine if the release is on schedule 
and report on progress of release. 
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• If schedules have to be changed, changes need to be authorized by all involved 
functions and components. 

How well does the tool integrate with other tools in the environment 

Release Planning and Release Control naturally use the same tool, typically a 
spreadsheet, for creating and maintaining the release schedule. 



Migration Control 

Migration Control is a function underneath Release Control. Updates to the 
distributed system must be tested prior to being released into the distributed 
environment. To control the updates as the move from the development into the 
production environment, Migration Control ensures that the proper updates are 
received from development, versioned according to the version strategy of Release 
Planning, moved into the test environment, moved form the test environment into 
the production environment after the pre release tests have been successfully 
completed. 

Implementation Considerations 

What units are subject to migration? 

The groups of components, which are allowed to be migrated, must be determined, 
for example: single software modules or documents can be migrated on their own 
and only complete releases (including delta releases) with all their components may 
be migrated. 
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Where will the release library be located? 

The library can either be held centrally or can be distributed over various sites. A 
centralized approach is preferable in order to avoid inconsistencies. 

Which platforms and media are used for the release library? 

The release library may reside of several platforms. UNIX software may be stored 
on UNIX servers, host software on hosts and third party workstation software may 
be on floppy disks. 



License Management 

License Management ensures that software licenses are being maintained throughout 
the distributed system and that license agreements are not being violated. 

Implementation Considerations 

What data will be stored? 

There are four options to consider, when designing the scope of the Asset 
Management function. Usage of the Asset inventory only as a production system 
database (core database), including hardware devices, software versions loaded in 
the production environment, their licenses and network configuration data. Thus the 
asset inventory system only stores the core systems components in the production 
environment. 
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In addition to the production system data as describes above, it contains any existing 
release and release components such as software modules, documents and 
procedures. It also contains service level agreements and actual figures for user 
groups and devices, incidents, problems and change requests. It may also contain 
additional data such as performance data or log of all backups taken. 

How will data be kept up-to-date? 

This can be achieved by regular and ad hoc audits, using manual and automated 
procedures. An alternative approach would be to use asset data to drive Software & 
Data Distribution. The Software & Data Distribution processes would get data from 
the asset inventory system as input If these processes configured the devices 
according to the asset inventory it would be up-to-date by definition. 

What phases of an assets life cycle should be covered by Asset Management? 

It may be appropriate to control assets within the first stage of the life cycle(i.e. 5 
from development on) or it my prove more appropriate to implement Asset 
Management only from the point of delivery. 

Product Considerations 

What is the intended use of the tool? 

Maintain a central repository for all software licenses and assets. 
What other utilities are available with the tool? 



• Software asset tracking by location / server, automatic detection of correct level 
of software. 
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• Authorize license use. 

• Perform periodic searches for unlicensed software. 

• Central inventory system 

• Ability to back up and archive the asset inventory system 

What are some of the inventory maintenance issues that need to be addressed? 

Ability to maintain a data model representing the basis for an asset inventory system 
that reflects the types of assets to be managed and their relationships. The model 
should be flexible to cope with future structural changes. A record needs to be 
added to the inventory system when an asset is purchased or created, or when 
changes to the environment are performed. 

How well does the tool integrate with other tools in the environment? 
Asset data needed to support various other management functions such as: 

• Hardware Maintenance 

• Release Testing 

• Procurement 

• Initial Installation 

• System Component Configuration 
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• Software & Data Distribution. 

Does the tool provide support for a specific environment? 

Current asset data from the distributed environment needs to be retrieved frequently 
through regular and ad hoc audits. 



Database Management is the management and administration of database 
technologies, including monitoring, physical file placement, performance, and 
sizing. 



Database Recovery 

Database Recovery is the process of providing recovery of database entities 
following a logical or physical database failure. This includes database software 
failure and local disk failure. 



5 



Database Management (9338) 



ro: 
m 
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Database Disaster Recovery 



Database Disaster Recovery is the process of recovering the database entities 
following a catastrophic failure. This process should be fully integrated in the 
enterprise-wide disaster recovery plan. 



# # 

- 376- 



Database Backup / Restore Management 

Database Backup/ Restore Management is the process of providing point-in-time 
backup and recovery for logical database restores. This includes application-driven 
data errors, dropped tables, and corrupt data. 



Capacity Modeling & Planning 

Capacity Modeling & Planning ensures that adequate resources will be in place to 
meet the SLA requirements, keeping in mind operational requirements which may 
require additional capacity. Resources can include such things as physical facilities, 
computers, memory/disk space, communications lines and personnel. Through this 
component, changes to the existing environment will be determined, modeled and 
planned according to the necessary requirements. 

Implementation Considerations 

What are some limitations that may be encountered? 

Capacity Planning & Modeling must coordinate the requirements across the system 
(e.g., networks, servers, workstations, CPU, etc.) Capacity is driven by the need to 
meet SLAs with the user communities and as part of the planning and modeling 
process, future threats to capacity should be identified. 

Capacity planning cannot, however, be done separately for each piece of the system. 
Capacity planning must be done for the system as a whole to understand how the 
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capacity of one portion of the system affects the capacity of another. Due to the 
large number of components within a distributed environment with any-to-any 
connectivity that will affect the systems capacity, the equation for determining 
capacity quickly becomes large, with many interdependencies. 



Monitoring (9340) 

Verifies that the system is continually functioning in accordance with whatever 
service levels are defined. 



Performance Management 

Performance Management ensures that the required resources are available at all 
times throughout the distributed system to meet the agreed upon SLAs. This 
includes monitoring and management of end-to-end performance based on 
utilization, capacity, and overall performance statistics. If necessary, Performance 
Management can make adjustments to the production environment to either enhance 
performance or rectify degraded performance. 

Implementation Considerations 

What are some of the critical elements to focus on in a centralized environment and 
distributed environment? 

Performance Management in a centralized environment typically focuses on three 
main factors: CPU utilization, disk I/O, memory occupancy. 
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Within the distributed environments, however, these factors extend out into the 
environment across networks, increasing the complexity of gathering the necessary 
performance information. 

View performance as a typically business driven? 

Performance Management needs to consider performance from a business 
perspective, not merely a systems one. Most transactions in distributed systems 
utilize a wide variety of resources, and the measurement of end-to-end response time 
becomes the sum of the time expended by each one of the components sequentially 
involved in the transaction less the time while components were processing in 
parallel. 

What devices / users will be monitored and at which locations? Will this 
information change? 

Understanding the scope of devices / users, and their locations is key to managing 
performance. Understanding whether or not the scope will change will help 
determine how Performance Management needs to be approached. 

Will performance be measured from end-to-end or merely for individual 
components? 

The issues associated with each of these approaches are described above. The 
approach chosen will have a profound effect on determining the issues that need to 
be resolved. 
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Will monitoring be continuous or by demand? 

Continuous monitoring can generate significant performance overhead, whereas 
targeted, periodic monitoring may only be necessary. This strategy will impact the 
design of the technical infrastructure as well as the tools chosen the manage the 
systems performance. 

Will only selected transactions be measured, and if so, should this selection be 
configurable? 

It may be necessary to measure business critical transactions only; specified within 
the SLA. If the facility to select specific transactions is required, significant 
customization of the system may be necessary. 

Will response times be required for all transactions of a particular type, or can 
sampling be used? 

Once transaction have been selected for monitoring, the decision needs to be taken 
whether or not every transaction of that type should be monitored, or only a sample 
set of those transactions. Full monitoring may increase network and processing 
overheads. 

The ability to dynamically adjust the system to improve performance is also critical? 

As SLAs will likely be tied in some way to performance, it is important to monitor 
and correct the systems performance as it degrades to ensure that operational levels 
are maintained and that the SLA(s) will not be violated. 
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Product Considerations 

What is the Intended use of the tool? 

Collect, analyze and display in graphical format real-time performance 
characteristics from a wide range of resources. Analyze current workload and 
configuration data and forecast future requirements, as well as providing input into 
the Financial planning process. 

What other utilities are available with the tool? 

• Provide real time monitoring and interactive tuning of the environment. Ability 
to input threshold alerting based on high / low watermarks and proactively act. 

• Monitoring capabilities include the ability to measure CPU and disk utilization, 
memory occupancy, transaction response time, reports (storage & distribution), 
printers, network utilization and performance, circuit utilization, backup 
facilities, WAN / LAN utilization.. 

• Instance level tuning and configuration parameters (memory, I/O, journalling) to 
address performance problems. 

Other integrated tools needed to provide support for this environment? 

May require use of some or all of the following monitoring tools: operating system 
monitor, on-line monitor, batch monitor, data base monitor, (host, server) and 
network monitor (WAN, LAN). 
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How well does the tool integrate and interface with other tools / components in the 
environment? 

• Performance measures must be consistent with Service Level management 
techniques 

• Performance statistics are essential to facilitate ongoing Capacity Planning and 
Modeling. 

• Resource utilization statistics may be used to generate costing, and potential 
billings for customers. 

• Passes data to the resource consumption management facility to report on the 
recurring processing cost of each business application. 



Physical Site Management 

Physical Site Management monitors the central and distributed sites environmental 
and regulatory levels. Physical Site Management ensures that adequate power, 
cooling facilities, fire suppression, etc. are provided and maintained to prevent 
system outages. When necessary, corrective actions are issued and monitored 
according to pre-defined environmental control plans. 
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Testing (9342) 

Ensures that changes to the distributed environment will not negatively impact the 
distributed environment and that changes will cause positive things to take place 
(e.g., better system performance, improved operability, etc.) 



Product Validation 

Product Validation tests potential hardware and software for the distributed 
environment prior to procurement to determine how well a product will fulfill the 
requirements identified. Product Validation also ensures that the implementation of 
a new product will not adversely affect the existing environment. 

Implementation Considerations 

To what extent will the production environment be reflected? 

The design of the test environment should reflect the production environment as 
closely as possible. In principle it is desirable to have an identical set up in both 
environments. However, this may be cost prohibitive and some parts of the 
configuration may not be critical to business^ The contents of the test environment 
therefore need to be decided. Yet it is difficult to judge which components of a 
distributed environment may actually impact services. For example, networking 
components, such as bridges, are often seen as transparent and not required in a test 
environment, which my mean that several LANs in production are only reflected by 
one LAN in the test environment. The risk of adopting this approach must be 
addressed thoroughly, and should be approved be senior management. 
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What are some limitations that may be encountered within a distributed 
environment? 

Because the technologies are new, it may not be possible to accurately assess what 
needs to be tested for a particular product. There are many configuration variants in 
5 the distributed environment, a single test environment for the validation becomes 
difficult to achieve and multiple test environments may be required. 




Release Testing 

Release Testing receives the proper version of a release package (e.g., software, 
data, procedures, support materials) and tests the release of the upgrade in a test 
environment to ensure that the: 

• entire release package is compatible with the existing environment 

• release package may be released successfully by the planned methods 

• release can be supported by support personnel. 
15 Implementation Considerations 

To what extent will the production environment be reflected? 

The design of the test environment should reflect the production environment as 
closely as possible. In principle it is desirable to have an identical set up in both 
environments. However, this may be cost prohibitive and some parts of the 
20 configuration may not be critical to business. The contents of the test environment 
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therefore need to be decided. Yet it is difficult to judge which components of a 
distributed environment may actually impact services. For example, networking 
components, such as bridges, are often seen as transparent and not required in a test 
environment, which my mean that several LANs in production are only reflected by 
one LAN in the test environment. The risk of adopting this approach must be 
addressed thoroughly, and should be approved be senior management. 

Will release tests cover the full business cycle and use full business volumes? 

To ensure that the Operability Principles have been satisfied, each release should, in 
principle, undergo a release test of a full business cycle (to show that Operations can 
run it) and full business volumes (to show that SLA targets can be achieved). These 
tests are, however, expensive in terms of dedicated hardware requirements, people, 
and elapsed time. 

In practice, Release Planning will propose an approach dependent on the magnitude 
and sensitivity of change for each release. The approach must be approved by senior 
management. If service levels are not to be compromised, major releases must 
undergo a full release test. 




REPOSITORIES (9344) 



Repositories contain all the management data generated or used during the 
management process. This includes historical data, capacity data, performance data, 
problem knowledge bases, asset databases, solution sets, and management 
information bases (MIBs). The repositories component interacts with the 
management applications, integration platform, supporting infrastructure, and 
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presentation components. Again it is important to make sure that the other 
components of the operational architecture are compatible with the database tools. 



Production Control (9346) 

5 Ensures that production activities are performed and controlled as required and as 
intended. 

C3 

j= Backup / Restore Management 

~ Backup and Restore Management considers all of the back-up and restorations that 

M need to take place across the distributed system for master copies of data. 

[ A 10 Depending on the need, these processes may occur centrally or remotely. 

fU; 

ru: 

Archiving 

yj 

Archiving saves and stores information across the distributed environment, either 
centrally or in distributed locations. Archiving moves datasets, files, etc. from one 
device to another, usually lower speed, device based on a number of parameters. 
15 Archiving can be used to move information to or from distributed and centralized 
sites. 



INTEGRATION PLATFORM (9348) 



20 



The integration platform provides a common platform for the operational 
architecture. At the lowest level this means deciding on common standards, 
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interfaces, massage formats, and file logging forms to be used with all the 
management tools. Third party integration platforms are also readily available. 
Some of the more well known platforms include IBM NetView, HP OpenView, Sun 
Solstice EM, SunNet Manager, Spectrum, CA-Unicenter, and Tivoli Management 
Environment. There are basically two types of third party platforms available. The 
first group are products like HP OpenView which are very modular. Each tool 
within the suite can be run separately, however, they all conform to a common 
framework which allows for greater compatibility and integration and better 
performance. The other group of products, including the Tivoli Management 
Environment, require the use of a separate integration platform component into 
which the management applications are connected. The integration platform and the 
management applications components of the MAP Operational Architecture Model 
are integrally related. Many third party vendors insist that they provide solutions 
which incorporate the event/data generation, event processing, repositories, and 
presentation components of the MAP operational architecture. It must be noted 
however that some of these total solution providers may sell a proprietary based 
solution, at best, and/or may include customized Application Programming 
Interfaces (API) or Software Development Kit capabilities in order to completely 
integrate your non-proprietary network. In Addition, some vendors also may not 
conform to the recent CORBA Open Standards Framework model. 



Lastly, some environments use a home grown integration platform. The choice of 
integration platforms depends upon its ability to integrate with the execution and 
development environments. 
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Network Management 

Network & Systems Management Planning is responsible for the planning activities 
involved in running the day-to-day operations and maintenance of the production 
systems (e.g., capacity planning, performance planning, etc.). 



SUPPORTING INFRASTRUCTURE (9350) 

The supporting infrastructure is the subset of operating systems, utilities, languages, 
and protocols used to support the management of the system. The supporting 
infrastructure is most often determined by the execution and development 
environments and the business applications on the system. It is necessary to ensure 
that the other components of the operational architecture are compatible with the 
existing supporting infrastructure. This limits the number of possible tool set 
solutions. Examples of operating systems include HP-UX, AIX, Solaris, SCO, 
Novell NOS, MVS, OpenVMS, NT and DOS. Examples of support utilities include 
PS, GREP, IBCOPY, TAR, CPIO and clock correlation. Examples can be broken 
down according to their function within the OSI model. Session protocols include 
SNMP, CMIP, FTP, and RPC. Transport protocols include TCP and UDP. 
Network protocols include IP and IPX. Data-Link protocols include Token Ring, 
Ethernet, X.25, ATM, SONET, and Frame Relay. 



Production Control (9352) 

Ensures that production activities are performed and controlled as required and as 
intended. 



J 
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File Transfer & Control 

File Transfer and Control initiates and monitors files being transferred throughout 
the system as part of the business processing (e.g., nightly batch runs). File transfers 
may occur between any two or more devises within the system. 

Implementation Considerations 

What platforms will be involved in the file transfers? 

The platforms will be determined by both the business and the technical 
requirements. This will impact the selection of the file transfer tools, and , in 
particular, how the file transfers are controlled from platform to platform. 

How many files will be transferred? With what frequency? 

The number of files to be transferred as well as their frequency will impact the 
capacity required on the system (e.g., network bandwidth) as well as the production 
schedule. In addition, if the volume of data is significant, data compression may be 
required. 

Will store and forward be supported? 

Store and forward techniques can help reduce the contention for system resources 
during business hours. Store and forward can also reduce the amount of traffic in 
the system based upon the routing tables defined within the system. Instead of 
having one machine send the same file to multiple machines, for instance, a 
cascading forwarding mechanism can be used. This also improves the system 
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performance as files are sent a minimal number of times to certain devices which 
then forward the files on to other devices. 

What are some limitations that may be encountered? 

File transfers in a distributed environment are not confined between hosts. File 
transfers can take place in a bi-directional fashion between hosts, servers and 
workstations. Due to the geographical disparity and number of devices in these 
environments, file transfers will increase the traffic over the network and will 
require careful scheduling to ensure that the necessary file transfers take place 
amidst the rest of the processing. 



MANAGING HARDWARE (9354) 



Managing hardware is all hardware directly used to manage the environment. This 
includes all staging components. These components are devoted to systems' 
management functions. Examples of managing hardware include management 
servers, management controllers, management consoles, probes, and sniffers. One 
significant component in the hardware monitoring arena is Firewall access control 
policy management. Firewalls are regularly used for network based security 
management. It is typically a system or group of systems that enforce access control 
between two or more networks and/or perform network data packet filtering. 
Usually packet filtering router hardware and application gateways are used to block 
unauthorized DP packets and enforce proxy defined user commands. 
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Failure Control (9356) 

Involves the detection and correction of faults within the system whether they be 
minor (e.g., workstation is down) or major (i.e., a disaster) has occurred. 



Disaster Recovery 

In the event of a significant system failure, Disaster Recovery processes will be 
invoked to re-route the system resources to a secondary, stable configuration until 
the primary resources can be restored. Within a distributed environment, disaster 
recovery must account for differing levels of disaster whether at a central or 
distributed site(s). 



Fault Management 

When a negative event has been brought to the attention of the system, actions are 
undertaken within Fault Management to define, diagnose, and correct the fault. 
Although it may be possible to automate this process, human intervention may be 
required to perform at least some of these management tasks. 

Implementation Considerations 

What are some limitations that may be encountered? 

In order to correct faults in a distributed environment, remote fault diagnosis and 
correction tools may also be required. It may not be possible to count on having 
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technical expertise on-sites, forcing fault management to be handled from a 
centralized area. Products which perform these functions at present, however, 
provide somewhat limited capabilities in this arena. 



5 Recovery 



Recovery manages all of the actions needed to restore service delivery after a system 
p failure. With critical business applications being rolled out on distributed 

~% technologies, the recovery of these systems must be easy, quick and efficient to 

M guarantee availability of core business systems as expressed in the agreed service 

£3: 

10 levels and operational levels. 



m 
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rij Hardware Maintenance 

Hardware Maintenance maintains all of the components within a distributed system 
to protect the investment of the organization. Generally agreed upon in the SLAs, 
15 maintenance contracts are carried out, monitored and recorded for each asset as 
appropriate. 

Implementation Considerations 

What will the Hardware Maintenance targets be? 



20 



Different hardware components will likely have different maintenance targets. 
These targets should be defined based upon information provided by the vendor as 
well as information provided from other client engagements. 
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Where will Hardware Maintenance be required? 

Hardware Maintenance maybe required at both the central and remote locations. 
Careful consideration must be given as to how the hardware at remote locations will 
be maintained (e.g., by a local expert, third-party vendor, etc.) 



Monitoring (9358) 

Verifies that the system is continually functioning in accordance with whatever 
service levels are defined. 



Event Management 

An event is an electronic message generated by any component (e.g., application 
software, system software, hardware, etc.) in the system. Event Management 
receives, logs, classifies and presents event messages on a console(s) based on pre- 
established filters or thresholds. 

Implementation Considerations 

What type of events will be monitored? More specifically, what services need to be 
monitored across which devices (e.g., servers, workstations, routers, hubs, bridges)? 

The scope of events to be monitored will have a major impact on the approach taken 
for Event management and the tools selected. 
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Where will devices reside on the network, and how frequently will they be polled? 

The number of devices, their respective locations and polling requirements will 
significantly contribute to network bandwidth usage. 

Where can event filtering be applied? 

In order to reduce bandwidth, it is preferable that event filtering be performed 
locally to avoid sending all event information across the network, utilizing 
bandwidth and central processing capability unnecessarily. 

What management protocols need to be supported? 

The protocol requirements will impact the selection of the tool. For more 
information on management protocols, refer to the management protocols using 
SNMP and CMIP as examples. 

What are some of the limitations that may be encountered? 

The number of events generated in the system will increase due to the complexity of 
the system. Devices will generate events as well as applications, the technical 
infrastructure, etc. Common event handling mechanisms will be required to provide 
management information in a simple, consistent format and to forward important 
events on for management purposes. In addition, filtering capabilities may also be 
needed at remote locations to prevent the streaming of events to central / master 
management consoles. 
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Performance Management 

Performance Management ensures that the required resources are available at all 
times throughout the distributed system to meet the agreed upon SLAs. This 
includes monitoring and management of end-to-end performance based on 
5 utilization, capacity, and overall performance statistics. If necessary, Performance 
Management can make adjustments to the production environment to either enhance 
performance or rectify degraded performance. 
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%| Physical Site Management 
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f\ 10 Physical Site Management monitors the central and distributed sites environmental 

b and regulatory levels. Physical Site Management ensures that adequate power, 

Mi 

cooling facilities, fire suppression, etc. are provided and maintained to prevent 
system outages. When necessary, corrective actions are issued and monitored 
y j according to pre-defined environmental control plans. 

15 Implementation Considerations 



What are some of the limitations that may encountered? 



Important to ensure that adequate power, cooling facilities, fire suppression, etc. are 
provided and maintained to prevent system outages from external environmental 
factors. With increased computing power at multiple sites, these tasks may not be 
20 simple. 
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PHYSICAL ENVIRONMENT (9360) 



The physical environment includes all the support indirectly involved in maintaining 
and managing the distributed environment. Initially it was thought client/server 
technology would make data centers obsolete. However, with the migration of 
mission critical processes to client/server environments, many servers are being 
maintained in data centers in an effort to increase reliability. As a result, the 
importance of managing the physical environment has increased. Partially because 
it was initially believed not to be very important and because it does not relate 
directly to the information systems, the physical environment of the operational 
architecture is often overlooked. These systems include UPS, raised floor, power, 
site survey and preparation, wiring/cabling, climate control, etc.. 

Related MODE functions The breakdown the MODE functions by operational 
architecture layer is meant to provide a guideline. The MODE functions mentioned 
within each component are applicable to that component though the function may 
not be included in that component. For example, Physical Site Management relates 
to the physical environment in that the physical environment contains the hardware 
managed through Physical Site Management. Physical Site Management tools do 
not necessarily reside in the physical environment layer. Some MODE functions do 
not require the use of a tool, while other MODE functions have tool solutions that 
work in different ways. For this reason some functions were included in multiple 
layers while other functions were omitted. 



Implementing (9362) 

Executes change within the distributed environment with tested components and 
techniques according to the appropriate plan(s). Implementing includes such things 
as: initial installation, software & data distribution, license management, etc. 
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Initial Installation 

Initial Installation prepares the physical location for the rollout of a new site or 
service, pre-assembles the equipment (hardware and software) based on developed 
specifications, installs the equipment and tests that the equipment is fully functional 
5 prior to allowing the users to utilize the system in a production environment. 

Implementation Considerations 

Some guiding principles: 

Precise build procedures must be delivered early enough to drive Release Testing, 
Procurement, and rollout plans. It must be clear exactly what the install process will 
10 cover. Who will perform which tasks when and where? Software and Data must be 
available in time to create copies for the hangar. This means development teams 
need to ensure availability of software up to a number of weeks before going live. 

To what extent will configuration be performed centrally prior to installation? 

Some of the configuration tasks can be performed in a central hangar. Assembly of 
15 the machines may include configuration and software installation. Only minor tasks, 
such as setting networking addresses have to be performed after the equipment has 
been delivered to the remote site. 
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Product Considerations 

What is the intended use of the tool? 

Prepare physical locations and devices (both HW and S W) for new rollout based on 
developed specifications and perform installation and functional testing of new 
devices prior to release to the users. 

What other utilities are available with the tool? 

Initial Installation must be able to load rapidly, reliably and consistently a large 
number of devices with a standard configuration. Automatic update of asset data 
accordingly, asset inventory must reflect the actual state of the devices; their set up 
and their networking address. 

How well does the tool integrate with other tools in the environment? 

During Initial Installation, software and data is loaded at the machines. The 
Software & Data Distribution function may be used to ship software and data to the 
location where it is to be installed (e.g. remote sites). 

Procurement 

Procurement is responsible for ensuring that the necessary quantities of equipment 
(both hardware and software) are purchased and delivered on-time to the appropriate 
locations. Procurement is also responsible for logging all assets into the inventory 
as they are received. 
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Implementation Considerations 

Will equipment be resourced from multiple or single suppliers? 

It is likely that organization will have close and long-term relationships to certain 
suppliers. In many cases, suppliers will offer discounts to their most loyal 
customers. These partnerships are advantageous for both sides, as long as they do 
not lead to supplier lock-in, i.e. the organization becomes technically dependent on 
one supplier. Technical portability and interoperability help support independence. 

What will be the payment policy (immediate or delayed)? 

A management decision is required, which compares cash flow benefits through 
payment as late as possible against discounts for early payment. This will usually be 
an extension of an existing policy. 

Monitoring (9364) 

Verifies that the system is continually functioning in accordance with whatever 
service levels are defined. 

Physical Site Management 

Physical Site Management monitors the central and distributed sites environmental 
and regulatory levels. Physical Site Management ensures that adequate power, 
cooling facilities, fire suppression, etc. are provided and maintained to prevent 
system outages. When necessary, corrective actions are issued and monitored 
according to pre-defined environmental control plans. 
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eCOMMERCE APPLICATION FRAMEWORK 



An eCommerce Application Framework 9400, which may be used to implement the 
various aspects of the VTrade system set forth above, is illustrated in Figure 94. 

FRAMEWORK OVERVIEW 

The eCommerce market is rapidly emerging. This is evidenced by the growing 
numbers of new eCommerce transactional sites, the increasing number of 'exchange 
of value' transactions performed daily, the emergence of new entities and businesses 
focusing on the electronic marketplace, the convergence and partnering of existing 
businesses on the electronic marketplace, and the empowerment of the everyday 
user to satisfy their needs within the evolving electronic marketplace. 

One definition of eCommerce is: 'A commercial exchange of value between an 
enterprise and an external entity — either an upstream supplier, a partner, or a 
down-stream customer — over a universal, ubiquitous electronic medium.' 

The eCommerce Application Framework includes several portions which may be 
used in a VTrade system, including: external agents 9402 which perform tasks 
automatically, electronic merchandising 9404 for performing eTransactions, 
relationship management 9406 for managing interactions between parties to a 
transaction, maintenance and administration 9408, order processing 9410 for 
managing the transaction, customer services 9412, security 9414, decision support 
9416 and integration 9418. 

The eCommerce Application Framework (eCaf) identifies and describes the 
application capabilities useful or necessary to implementing eCommerce business 
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solutions. It provides a framework to tie business process, application, and 
technology aspects of eCommerce together, and a basis for mapping and assessing 
the capabilities of the eCommerce packaged solutions. This framework should be 
used as a vehicle for communicating, and designing eCommerce business solutions. 

The eCommerce Application Framework has been created to provide an 
understanding of the types of services and applications needed to implement an 
eCommerce solution. Figure 95 illustrates the relationship between. the eCommerce 
Application Framework 9400, possible eCommerce Selling Models 9502, enabling 
technology 9504, and enabling eCommerce Software Packages 9506. 



^Jj 10 The eCaf defines a supporting middle layer between basic Internet or Netcentric 

enabled products (eCommerce Package Software) and the technical infrastructure 
(Enabling Technology) needed to develop eCommerce-enabled web sites based on a 

Mi 

s business-specific selling model (eCommerce Selling Models). Note that eCaf just 

l*j covers the middle layer. 



15 Each solution or site may have a different selling approach, architecture, utilization 
of technology, or applications. The eCaf includes the concepts, applications, and 
services common across the different solutions and has organized them into 
application capabilities. 

Technologically eCommerce business capability requires a logical grouping of 
20 services enabling a specific eCommerce functionality. The functionality may be a 
single technical service within the underlying architecture or an entire application. 
The capabilities have been derived from surveying multiple eCommerce software 
packages and eCommerce implementations. As eCommerce evolves, the categories 
and capabilities are apt to change. 



25 
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eCommerce Application Framework 

The eCommerce capabilities illustrate the highest level categories of eCommerce 
capabilities: External Agents, Electronic Merchandising, Relationship Management, 
Maintenance & Administration, Order Processing, Customer Services, Security, 
5 Decision Support, Integration. 



The capabilities within a given category may cover the full range of potential selling 
models. Some components may be specific only to a business-to-business buyer- 

H 

^ centric implementation. Additional components may emerge as this technology 

matures. 

£3; 

O; 

J2; 10 

«y! eCommerce Enabling Technology 

n 
A 

y J The enabling technology for an eCommerce implementation is the same underlying 

™" technology used to enable most Netcentric (and in some cases client server) 

implementations. In general, most implementations will utilize the Netcentric 
15 technologies. An understanding of the Netcentric framework will act as a building 

block for understanding the technology aspects of an eCommerce solution. 



eCommerce Selling Models 

A wide variety of eCommerce solutions fall under the broad umbrella term of 
20 "eCommerce." The vague definition of eCommerce lends itself to a range of 

implementations and possibilities. A survey of the sites within the current electronic 
marketplace reveals the majority of the transactional 'exchange of value' solutions 
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concentrate on selling 'products.' Products can be further divided into physical and 
electronic. 

• Physical - Any tangible product the buyer can touch or feel (for example, 
cars, refrigerators, food, or furniture). This would include retail and durable 



• Electronic - Any product delivered over an electronic medium. This may 
include content, information, audio and video, or software (for example, 
music, or financial products such as insurance or mutual funds). 

Across the many 'exchange of value' sites, there are three prevalent selling models: 
10 seller-centric, buyer-centric, and auction. 

Seller-Centric Selling Model 

The seller-centric model is the most common. In its simplest form, a company 
typically provides information about their products and gives the customer the 
ability to place orders. More advanced implementations use electronic means for 
15 supporting the entire sales and support process including: marketing, product 
display, merchandizing, customer needs assessment, order processing, and many 
other activities. In most seller-centric solutions, the infrastructure is created and 
maintained by the merchant. The customer needs nothing more than a browser 
and/or access to the site. 

20 Buyer-Centric Selling Model 



5 



goods. 



In a buyer-centric solution, the main focus is on customer or buyer trying to fulfill a 
need for a product. In contrast to Seller-Centric sites which offer products, a buyer- 
centric site displays items the buyer would like to purchase - in effect trying to lure 
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sellers. Many of the same capabilities as seller-centric sites are needed such as order 
management and payment capabilities. In this case, the customer joins or creates an 
infrastructure focused on fulfilling his needs. The infrastructure typically provides 
an environment between the trading partners which promotes browsing and 
comparing products, ordering products , fulfillment, payment, and any needed 
customer support services. A concentration should be placed on the ease of 
transactions and information flow. For this reason, sellers may customize their 
product line to the buyers' specific needs. 

In most buyer-centric cases, the buyer or often a consortium of buyers, provides the 
bulk of the eCommerce infrastructure. Additional integration and setup may or may 
not be required for each of the trading partners who wishes to participate. 
Implementations requiring sellers to specially configure or integrate their own 
systems in order to participate are usually only successful where the buyer has 
substantial market power in the relationship, as in GM ® or Ford ® buying parts 
from their suppliers. In such cases, agreements must be made as to what 
information is to be shared, how to model the information, the standards for 
messaging and communication, and what technologies will be used. Besides the 
technical hurdle of integrating multiple systems and the somewhat immature state of 
the software products to date, convincing trading partners to adopt an Internet 
commerce approach can also be very difficult. If one is not a particularly big or 
powerful buyer, it can be difficult to attract potential sellers to come to one's site 
and spend the time necessary to learn about one's needs. This requires sellers to 
engage in a very different activity than they have traditionally performed and many 
are not eager to change their way of doing business for a relatively small customer. 

This section of the market has been slower to emerge. As mentioned above, trading 
partner maintenance is a key issue. Companies at the end of the hub must buy into 
the hub's practices and vision. Future vision and direction are also important. As 
changes are implemented, all trading partners have to move together. Getting buy in 
from all partners has the potential to slow down the adoption of new technologies 
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and process innovations which over time can lead to a lack luster lowest common 
denominator approach. 



Broker Selling Model 

5 Broker or auction type solutions are also emerging, albeit more slowly. Broker 
implementations don't typically sell their own goods, but rather provide an 
eCommerce environment to facilitate bringing multiple buyers and sellers together. 
Both buyers and sellers can utilize the broker's site and infrastructure rather than 
developing and maintaining their own eCommerce capabilities. In this case, a broker 
10 has set up the infrastructure needed to buy and sell goods. The infrastructure will be 
very similar to a seller-centric solution with the addition of components needed to 
register goods to be sold (or in a buyer-centric twist - register RFQ's 'request for 
quote'), price negotiation and bidding, and reconciliation services. 

A Trading Network (TN) is an excellent business example of a broker site. Users of 
15 the TN can issue Request For Quote's (RFQ'S) on the trading network. The request 
could be for raw materials, components, or finished items. Suppliers are free to 
answer an RFQ providing they meet some basic guidelines and requirements. The 
network provides a true win-win relationship. Since the network can be global, 
suppliers the purchaser may never have known about are free to participate. 

--- ] 

20 Another example on the consumer side is a sales website. Such a site offers a 
variety of computer, electronic and fitness goods as well as a general merchandise 
auction. Customers can browse items in order to view product information and their 
current bid prices. Interested buyers can place a bid online and see how their bid 
price compares with others. The auctions are time based and follow a detailed 

25 bidding process. As customers are out bid, they are notified via email and have the 
option to reply with a counter bid. 
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Packaged eCommerce Software 



In relation to packaged eCommerce Software, the eCaf framework provides a basis 

for understanding and assessing the capabilities of the eCommerce packages. 

i 

5 If a package is used to implement part of the eCommerce solution, an analysis of its 
underlying technology and business requirements with respect to the Netcentric 
Framework and the selling models should be conducted. It is important to 
^3 understand the underlying architecture and any inherent application limitations due 

: =3 
«S3; 

i j to the package's choice of technology used to implement its architecture. In short, it 

™ 10 is important to understand what comes 'out of the box.' Be sure to understand each 

d 

J i of the main components described by the Netcentric Framework (e.g. Web Browser, 

U 

1 Web Server), how the components communicate, and any limitations of the package 
and architecture of the component. 

ru 

y3 A multitude of different packages are emerging usually with the name sounding 



15 something similar to 'eCommerce Server.' Each package may boast to be different 
in the problem it is addressing, the architecture, or the underlying processes and 
technology. In addition, it may claim to provide an 'end-to-end solution' for 
businesses wishing to transact on the Internet. It is currently very difficult to 
differentiate between the products. The eCAF provides a basis for understanding 

20 and assessing the capabilities of existing eCommerce packages as well as those 
emerging. 



The current eCommerce software packages can be classified in the following 
categories: 
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• eCommerce Toolset This category would includes any set of tools or 
components with which an eCommerce application can be built. 
Examples include the multitude of 'CyberWallets' or electronic cash 
components. 

• eCommerce Internet Applications This category includes software 
geared toward providing an application for specific eCommerce business 
functions or processes. This product would be a template or is in itself a 
specific eCommerce-enabled application. An example would include 
products providing the ability for cataloging or help desk functions. This 
is often referred to as vertical solutions. 

• eCommerce Transactional Infrastructure This category includes 
software packages providing the infrastructure to support multiple 
transactional eCommerce applications. These types of solutions provide 
the transactional infrastructure used for multiple sites. 

A complex eCommerce solution potentially may utilize software from all three of 
these categories in addition to any custom code needed to integrate them. 

The Relationship Management section of the Ecaf, shown in Figure 96, covers 
applications and architecture components geared toward capitalizing on the 
interaction with the customer. Within relationship management, there are two main 
driving forces: Interactive Marketing 9602 and Personalization 9600. 



Personalization 9600 



# 
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Personalization is the continuous process of collecting, analyzing, and using 
information about the end-user in order to improve the productivity and value of 
their interaction with the organization. 

The purpose of personalization is to interact with the customer/user with the hopes 
of establishing and building a relationship, increasing sales by catering to the 
individual customer's needs, cross selling or up selling, and enticing users to return 
to the site. Unlike any other broadcast medium, the Internet was designed for two- 
way interaction, hence providing the ability to narrow-cast or customize the 
interaction to the individual user. 

Generating demand for a site's products or services and building customer 
relationships are crucial for any eCommerce implementation. This is even more 
evident in seller-centric implementations and hype or marketing driven 
implementations. The customization can occur in many forms. The services and 
infrastructure can vary drastically depending on the extent of personalization 
desired. Each eCommerce package may approach personalization using different 
services and infrastructure. 

The enterprise complexity of the personalization approach will drive the architecture 
components and application required to implement and deliver this strategy. It is 
critical for the enterprise success to understand how the personalization strategy will 
20 affect the entire enterprise. 

Conceptual Personalization Architecture 

The conceptual personalization architecture is independent of enterprise or industry. 

Implementing a personalization strategy into an existing system or a new one 
requires the design and development of personalization architecture components. 
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These components are essential to the success of the personalization strategy. They 
include an Identification component 9610 to identify the user, Information Capture 
component 9612 to capture information about the user, Content Catalog component 
9614 to manage the different contents in the system, Matching component 9616 to 
5 match the user's profile attributes with the correct content, Merge & Deliver 
component 9618 to deliver the content to the user and an Optimization & 
Administration component 9620 to continuously optimize the personalization 
interaction and administrate the rules and content as they change or added. See 
Figure 96. By way of example, the conceptual personalization architecture 
10 components illustrated in Figure 97 will be discussed in detail in the subcomponents 
of this component. 

Personalization Techniques 

There is currently a lot of hype and press attention centered on the idea of 
"personalization". Given the wide variety of products and ideas being labeled 
15 "personalization", it is apparent that a variety of different personalization delivery 
techniques and technologies are evolving. As with most emerging concepts, the 
initial techniques cover a wide range of complexity in both infrastructure and 
approach. Most personalized sites use a combination of techniques. Samplings of 
personalization techniques are presented below: 

20 User acknowledgement 



This is acknowledging the user or greeting them with a personalized 
statement. The statement may be a simple 'Welcome back <user name>!' 
message or it may be more complex, drawing on information from the last 



interaction. 



25 



Personalized interface 
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In this approach, the application or web site's user interface is customized for 
the individual. The actual page layout or page design is altered based on the 
individual interacting with the system. This category can be sub-divided 
based on who (the site or the user) controls how the interface is altered. 

• Site Morphing. Site morphing is when the site alters the user's interface. 
The site may alter the page's layout, the subjects or types of content and 
information, or the site capabilities based on what is known about the 
user. A variety of different user attributes or algorithms can be used to 
customize the user's interface. 

1 . Customer Strategy. The site's interface may alter based on a 
customer status or customer strategy. A customer strategy might 
attempt to interact with new site visitors with an interface geared 
toward selection (what is the potential value of this customer?) 
and acquisition (how do we acquire this customer?) while gearing 
the interface and interaction for an existing customer to retention 
and extension (selling additional products, allowing the customer 
to be self serving, or making it easier to do business with the 
company). 

2. Customer Status. The site's interface can be altered based on the 
status of the customer. For example, a United Airline ® site 
could be customized based on the user's Mileage Plus ® status. 
Non-members would have a very generic site where they can 
perform the basic site functions. Mileage Plus members would 
have additional capabilities (such as flight history, mileage status 
or customer service chat) as well as different site layouts and 
attributes based on their exact status. 
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3. Intent Determination. This technique attempts to pre-determine 
the purpose of the user's visit to the site and customize the 
navigation and user interface to help the user quickly perform 
these actions. Based on the user's information and past actions, it 
can often be determined the most likely reason the user is logging 
on and thus make those functions or information immediately 
available - front and center. Assume the United Airline site used 
intent determination to create a personalized interface. Over time, 
the site learns that the user regularly check their mileage status, 
the in-flight movie listings, food service listing, and airport maps. 
The site also notices that the last two interactions, the user has 
called to upgrade to First Class. The next time the user logs in, 
realizing the customer has an upcoming flight reservation to 
Chicago, an O'Hare terminal map, the in-flight movie, and dinner 
menu is automatically displayed as well as a prompt asking the 
user if they would like to upgrade to first class. The power of this 
concept becomes increasingly important as more functional web- 
sites are deployed that allow the user to do possibly hundreds of 
different things. Users are already complaining about the ability 
to navigate even relatively simple sites. Personalized intent 
determination seeks to "de-clutter" the company's site and 
demonstrate to the user that the company "knows" them and what 
is important to them. Good intent determination is not easy to 
implement, but holds real power for making customer-based 
applications easier, and more likely to be used. 

User Configured Interface. The user controls the site's configuration. 
In this case, the site provides a facility that allows the user to configure 
the page layout, and the subjects, links or content that the page will 
contain. Once configured, the user has a customized page configured to 
their specification. When the user enters the site, the user-configured 




-411 - 



interface is loaded. Within the user-configured site, the user has the 
ability to configure their own site by selecting the layout, topics and 
content details that will be displayed by selecting items from defined 
menu of configuration options. 

Content filtering 

This technique filters the information or content displayed to the user based on what 
is entered by, or known about the user. Many personalized sites use some form of 
content filtering. A variety of different filtering techniques have emerged. Some are 
adaptations of traditional client/server techniques adapted to the Web. In the first 
grouping of techniques presented here, the user controls how the information is 
filtered. 



• User-controlled, explicit content filtering. Techniques in this 
category enable the user to filter data or content. 

o Personalized Information. Allows the user to see 

information specific to them. The content in this case may be 
information about the user's profile, about products they have 
or a past order history. This technique allows the user to 
filter the data by building 'where clause' statement or execute 
'canned' queries. It is often used when the user is familiar 
with the data and wishes to organize or filter it in multiple 
ways. 

• User-controlled, implicit content filtering. 

o Collaborative filtering. Collaborative filtering determines 
clusters of users with similar interests, either by asking users 
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explicitly or by observing user selections and actions to 
determine those interests implicitly. This is an effective 
technique for creating recommendations for products. 



• Site controlled content filtering. 

5 o Contextual Inferences. Contextual inference uses human- 

determined rules to select content based on behavior, interest 
or other profile attributes. 

a 

*i3 o What's New. Based on knowing when the user last 

ejsi. 

visited, the site determines what content has changed since the 
10 last time the user has interacted with the site and display a list 

=ff of changes. A personalized "what's new" is far more effective 

M 

5 than a generic "what's new" that is shown to all users - 

l*j obviously what's new is different for the user who was here 

fO. yesterday versus the one who hasn't used the site in six 

15 months. The content that is marked as new may be further 

"3" constrained to only contain the areas that the user has 

interacted with in the past. 

Configure process or fastpath 



This technique simplifies a complex process or repetitive task by storing the user's 
20 preferences and inputs required to complete the process. In most cases a series of 
pre-defined questions and preferences have to be set up in order to use this 
functionality. 1 -Click purchasing can be offered which allows a user to select an 
item with a single click and purchase the item ~ by-passing the order selection, order 
form, shipping and payment pages. A Fastpath approach can be used where the user 
25 has performed the function before and allowed the application or web site to retain 
more static information like shipping address. 



ru 
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Pre-filled forms and information 

In situations where user data is required to complete an action, the site can use 
information that it currently has about the user to pre-fill the form. For example, the 
site may fill out the order form with the user's last address and order information or 
5 the site may fill out the list of items ordered last. This approach differs from 
Fastpathing in that the user still sees the pre- filled form and has the opportunity to 
change the data. 

ad 

s3 Personal assistant 

H 
£1 

□ The site provides an interactive assistant to deliver 'personalized help and 



!^ 10 assistance'. Its purpose is to help the user with difficult actions and site 
a functionality. Based on observing and recording how often (if ever) the user has 

=y used a give function within the site, tips, suggestions, and other forms of assistance 

can be fine tuned to the user's level of experience. 



Non-interactive delivery techniques 



15 Most of the personalization techniques described above are interactive 

personalization techniques. Content and information is personalized for the user in 
real time - while the user interacts with the application or site. Some forms of 
personalization can also be used in a non-interactive, or "push" mode 

"Push" (or "server-push") is where the delivery of information to a user on the Web 
20 is triggered and initiated by the information server rather than by the user. 



In fact, the information pushed from a server to a user actually comes as the result of 
a subscription-like standing request created by the user and either stored on the 
server or on their local machine. This program captures and stores the user's profile 
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locally and then periodically initiates requests for information on the user's behalf 
from the server. 

Push technologies enable an enterprise to reach and provide value to their customer 
outside of the traditional interactions. Of the personalization techniques described 

5 above, content filtering doesn't require that it be delivered though an interactive 
session. Keep in mind that push does not necessarily mean personalized. A site may 
simple push the same information to all users or subscribers. Personalized push 
refers to information that is filtered based on a specific user's request or profile or 
where the delivery is scheduled for a specific user. There are a variety of different 

10 legitimate business reasons to push a users information. The following are some 
examples of personalized push: 



G 



• Information Delivery. A user subscribes to receive information on a 




15 



scheduled basis. The information that is pushed is either determined 
through user selection - the user selects the subjects and type of 
information that they wish to receive, or the site determines what 



information the user may be interested in receiving based on their profile 
information. For example, at an investment web site, users are allowed to 
subscribe to investment information feeds. The user decided to receive a 
daily feed of the stock quotes for the commodities they hold. The site 



20 



pushes this information and additionally pushes news articles and stock 
recommendations based on the user's portfolio holdings. 



• Event Reminders. The user subscribes to receive event reminders from 



25 



the web site. An event reminder might remind the user of specific dates 
of interest such as a birthday or anniversary, a bill reminder or that an 
action is required in the near future. 



• Information Update. A site may also push updates to a user. For 
example, Microsoft's Expedia allows users to request fare updates. A 
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use r can choose a specific destination of interest. If the fare to this 
location changes, the user is notified of the fare update. 
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Don't be a junk e-mailer. The push medium is powerful and potentially less costly 
than conventional mail. This doesn't justify its use as junk mail. It does not work 
5 because everyone receives junk mail, and junk mail that ends up in the trash is failed 
target marketing efforts. Personalize it. Deliver valuable information that the 
customer is interested in. Allow them to select the topics, how to filter the content 
and the frequency. 

Personalization Process 

10 Personalization is actually a catchall for several underlying technology capabilities 
needed to create a personalized interaction between an organization and a user. By 
breaking the underlying technology and logic into simpler components, one can 
build an understanding of the processes and technology needed to deliver 
personalized applications. 

15 Personalization is the continuous process of collecting, analyzing, and using end- 
user information in order to improve the productivity and value of their interaction 
with the organization. Implicit in this definition is the need to do a number of basic 
things. Simply put, there needs to be some method for identifying the user, 
collecting (or detecting) and storing user information, analyzing it, assessing what 

20 content or functionality is appropriate, and present it to the user. 

Figure 98 illustrates a simple personalization process 9800. Most personalization 
techniques utilize this process in some fashion or another. The complexity and the 
details of the process may vary based on the technique. The following is a 
description of the different personalization process components. 
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• Identification 9802 - The first step is to identify the user. This enables the rest 
of the personalization process components. One must know whom one is 
talking to, in order to personalize "personalize" the experience. 

• Information Capture 9804 - The next step is to collect information about the 
user. This may be done with implicit or explicit techniques at the direction of the 
user, or controlled by the system. The goal is to capture information that will 
assist in determining and delivering a valuable interaction. 

• Analysis and Refinement - Once the data is captured, it may need to be refined 
before it is usable. The system needs the ability to analyze the data and draw 
insight or conclusions about the information and interaction. The refinement 
may transform the data from questionnaires or implicit observation to be usable 
with the matching rules and content indexing strategy. 

• Match 9806 - When the personalization strategy is developed, a base of 
'Personalization Matching Factor' and rules (based on who, what, where, when, 
why. . .) are created. These matching factors and rules are necessary to determine 
the content, navigation, and layout appropriate for the user. 

• Merge and Delivery 9808 - Upon determining the appropriate information and 
format, the information needs to be merged and deliverer to the user. This may 
be through an interactive interface or through a push mechanism. 

• Personalization Optimization 9810 - Personalization is a complex and 
evolutionary process. The ability to gather metrics and measurements on the 
personalization process in order to perform rule or data translations, model 
tuning and reporting is essential to maximizing the concept's potential. 

Personalization Strategy 
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Personalization will continue to be adopted by the market place. Numerous sites 
have incorporated personalization techniques into their sites and the marketplace is 
full of independent software vendors creating personalization related software. 

Each enterprise must assess their personalization opportunities from their own 
perspective and develop their own personalization strategy. The personalization 
strategy must be integrated with the enterprise's existing customer relationship, 
technology and eCommerce strategies. 

Developing a personalization strategy 

Using the Opportunity matrix given below, the opportunities where personalization 
typically delivers the most value in within the Interact domain. This area consists of 
opportunities where the organization is interacting with the user or the user is 
attempting to engage in a dialog. The publishing slice and Knowledge Management 
aspects of the Interact slice are the areas which are typically the secondary areas of 
personalization opportunity with the transact slice being last. 
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Process 



Publish 



Interact 



Transact 



Develop Research and product 

products and information 



services 



Capture customer Integrated design 
feedback; 

Systems 

co-design 
products 



Generate Product information; Interactive 

Demand marketing; 

advertising 

Market of One 



Demand-generated 
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When evaluating what opportunities exists, all areas should be considered. The 
value of the personalized interaction will be dependent on many factors such as the 
type of products and services (can they be personalized?) or the type of relationship 
with the customer or consumer and the ability to capture user information. 
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A formal personalization strategy should be established that included the near term 
goals and future vision. Many companies jump right in without any guidance or 
realization on how they are growing or enhancing the enterprise. The strategy 
should begin with the big picture. Perform an examination of the critical forces 
5 affecting the enterprise and how these forces affect the business process. What are 
the drivers? Society, marketing, technology, business/industry? With the 
personalization market emerging, there are still with many unproven business cases 
and unproven technology. Firms should not engage in personalization simple 
because they can, nor should they fall prey to the unproven expectations generated 
f3 10 by vendors or marketing hype. Firms considering personalization must frame 

personalization in the context of true enterprise goals (increasing customer retention 



-4; or increase customer extension), then determine how personalization will help 

accomplish these goals. 



The personalization strategy should evaluate the complexity of the personalization, 



fU 15 the cost and time to implement and the potential business impact. In many cases, a 



true one-to-one personalized site may not make sense. Creating millions of varieties 
€£■ of a product will only complicate the interaction to the point that the user is 

overwhelmed. In some cases engaging in simple personalized dialogues may be the 
best near and midterm solutions. 



20 Since different users may wish to interact differently, there may be many right 
answers to the personalization strategy. Some users are self serving and want to 
have the tools to explore or make choices on their own, others want immediacy, 
others may want intimacy such that their feed back and options register with the 
company. See Figure 99 for a graphical depiction of personalization from no 

25 customization at 9900 to one-on-one personalization at 9902. 



The type of dialog that the site engages with the user may vary based on the user. In 
some cases no personalization or customization should be performed. As more 
information is captured on the user, the correct type of dialog should be assessed. 
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Determining the correct touch points and level of complexity of the personalization 
techniques is an important part of the enterprise's personalization strategy. 

Common Impediments to Personalization 

Listed below are some of the common impediments to personalization. 

1. Cost - The cost of implementing sophisticated personalization is 
very high. The annual cost of maintaining a highly personalized 
Web site will likely be even greater than the implementation cost. 

2. Software Immaturity - Several of the Web measurement and 
analytic techniques used to segment users based on behavior and 
preferences come straight from academia and have not been 
adequately tested in the real world yet. 

3. Vendor Immaturity - Many of the vendors offering the most 
sophisticated personalization software are small start-ups founded 
by academics. These companies are still developing their 
strategies and growth plans, and are liable to change course over 
the next few years. 

4. Content Management - Content must be created and stored in 
such a way that it can be flexibly combined and frequently 
modified. 



5. Integration with marketing databases - To be more than a 
novelty, personalization will require tight integration with 
marketing databases. This presents a serious integration 
challenge, and may necessitate the creation of an enterprise wide 
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strategy for the collection, normalization and analysis of customer 
data. 

6. Required Maintenance - Personalization requires dedicated 
maintenance. While much of the process of personalization can 
be automated, the construction of the business rules used to match 
content to visitors and the creation of the metadata tags required 
to classify all content still require a tremendous amount of human 
oversight. The need for such oversight is only compounded by the 
fact that personalization becomes exponentially more complex as 
the number of visitors and amount of available content increases. 
The net result is that firms that decide to engage in 
personalization without ramping up staff adequately will fail. 

7. Personalization Failure - If the personalization technique fails 
to deliver the correct message or product, the result may be 
devastating. The last thing a personalization technique should do 
is destroy or damage relationships. 

Implementation considerations 

The architecture components and processes will differ depending on the type of 
personalization technique implemented. For each technique, there are important 
considerations and differences that should be understood. Each technique will vary 
in approach, information required, and delivery. The following items should be 
considered: 



1 . Triggering the Personalization Process - What triggers the 
personalization process? Does the user control the process or 
does the site? Is the process triggered when the user requests a 
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page or DCA within a page or is it triggered by a background 
process based on implicit information capture? 

2. User Profile Information - What information does the 
personalization process require? What is the data source or where 
is the information stored? How and when is it captured? 

3 . Matching Logic - What drives the matching logic? How is the 
rule defined? Can the user configure the rule? Does the rule 
optimize and learn by itself? What happens if the information 
needed does not exist, does the site attempt to capture it? 

4. Content - What is the potential content? How is it stored? How is 
the content merged and displayed? What is the extent of content 
management? 

5. Definition and Maintenance - Who is responsible for configuring 
and maintaining the rule, matching logic, or Personalization 
technique? What are the metrics that will measure its ROI? How 
are these metrics captured? 

These questions can be answered in many ways. The impact the answers have is 
dependent on the enterprise and its personalization strategy. 

A few specific techniques to consider are detailed here: 

1 . Personal Acknowledgment - In the case of a personal acknowledgment, the 
rule set may be well defined and the user is not even aware that it exists. There 
is also no way for the user to alter or customize the content. An example of the 
personal acknowledgment would be a simple greeting that says "Hello <User>, 
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Good Afternoon". The rule is based on time of day, as determined by the system 
time. Once the user enters the site, the rule is executed. Based on the result to 
the system would greet the user with a 'Good Morning, Good Afternoon, or 
Good Evening'. In this case, the rule is set and does not get altered. 

5 2 . Content Filtering - Content Filtering works very similar to personal 

acknowledgment, but it allows the user to alter the content they wish to see. The 
rule set is not as clearly defined as personal acknowledgment, rather a shell of 
the rules is in place and the user has the ability to customize the attributes to the 
rules. Content Filtering allows the user to define what it is they wish to see on 

10 their page. On a site, the user is able to select what information is important for 
them to view. Users can select whether or not they want to see information 
about sports, weather, U.S. news, World News, states, and many more. 
Whichever options the user selects, are the types of stories that will be displayed 
on their personalized page. The user should also be given the option to change 

15 their options at any time. In this case, the rule shell is defined, however the 
attributes are changeable by the user at any time. 

3. Custom Interface - The Custom Interface example takes the concepts of 
Content Filtering one step farther. In this case, the user not only has the option 
of setting the content attributes, but they are also able to set the page attributes as 

20 well. By giving the user the ability to set the page attributes, they set up the 

layout of their page so the items are what they want to see, and where they want 
to see them. Here, the same form of the rule shell is used, but the user also gets 
many other options that allow them to set up the page as they desire. 

4. Personal Assistant - The idea of a personal assistant has been popularized by 
25 Microsoft in their addition of the personal assistant to Microsoft Office. If one 

begins to have trouble or is unable to figure out what to do, the Personal 
Assistant is there to help. This type of interface is different from that of the other 
types mentioned. In this example, the system is designed to be a learning system 
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and is situation based. That is, it is designed to monitor what actions the user is 
performing and trying to determine if the user is lost. If the system notices the 
user is continually returning to the section of the site designed to change their 
address, but has not been successful in getting their address changed, then the 
5 personal assistant would be launched. The assistant would try to help the user 
follow the needed steps to change their address successfully. This type of site is 
not built upon hard-set rules, but rather is designed to learn as much as possible 
about the user as it goes. 



q 
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The first task of the personalization engine is to identify the user. Unlike the 
E everyday person to person interactions where a person relies on recognizing the 

?y. another's face, voice or other attributes to identify the other person, identifying a 

[ij user on-line can be a difficult process. The simple task of identifying users does not 

S 15 prove to be a simple task at all. A system may personalize an interaction based on 
^- the information captured during a single session or information gathered over the 

entire duration of the relationship. Regardless, the information that is captured needs 

to be associated with the user. In order to track a user, an identification or tracking 

mechanism needs to be created. 



20 Identification Techniques 

A variety of techniques can be used to identify the user. The technique may depend 
on the site's security requirement and privacy concerns. Today, the most common 
approaches are to either create a cookie on the client machine or to have an 
identification system on the server, such as a user login. In the future, digital 
25 certificates will be more prevalent, and should become the dominant identification 
method. 
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Client side storage-cookie 

A Cookie is a small text file placed on the client machine's hard drive by a Web 
server. It is essentially a user's identification card, and cannot execute code or 
deliver viruses. It is unique to the user and can only be used by the server that issued 
5 it. Although this is a common method for identifying a user, there are many risks 
associated with it. 



Cookie may expire or be deleted by the user. 



C3 
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Multiple people may use the same client machine. Identifying 



10 



what user is on the machine may be very complex. This may 
result in multiple cookies or a complex cookie that can identify 



multiple users. Regardless, the cookie may not be able to 
determine what user is currently on the system. 



15 



A user may use multiple machines. In this case, the new/other 
machine may not have the user's cookie and will not be able to 
identify the user. 



The user has the ability to disable the use of cookies within their 
browser. There is an option that the user can set that will tell 
their browser to reject all cookies. If the user does this, then he 



or she will be unidentifiable . 



20 Server side application logic 



This technique requires the user to log-in or sign on to the site. This requires the 
creation of a user ID and password to utilize the system and the resources needed to 
validate and store the ED and password. With this technique, the user must 
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remember their log-in name and password. Additional services to lookup log-in 
names or request new passwords should also be provided. 

Certificates and digital ID 's 

In every day life people carry different forms of identification; a person's on-line 
identity may be no different. Modern cryptographic technology offers certificates or 
digital IDs that will serve as electronic forms of identification. Digital certificates 
are still evolving and the key players and details on how the pieces tie together are 
still falling into place. 

One example of an effective use of a certificate is Firefly Passport. There the 
certificate is tied to a list of user profile information. (Microsoft purchased Firefly 
for this technology. The name is apt to change over time.) The Firefly Passport 
gives users an application with which to control their personal information and 
payment details. The information can be dispensed selectively to third parties to use. 

A combination of techniques may also be used. The cookie may be used for the 
initial identification or the default ED for the Log-in process, while the server side 
log-in process would then be used to verify the identity of the user. It is important to 
make this process seamless and unobtrusive. The identification process should fade 
in the background. It should be present yet invisible and unobtrusive. 

Relating Multiple ID's 

Creating a log-in or sign-in process introduces the traditional problem of multiple 
log-ins, (or ID's) from a site or enterprise perspective. If a user forgets their login, 
they may simply create a new one. This may result in multiple logins for the user, 
and any information related to the previous login is not associated to the user's new 
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one. To prevent this, a facility to look up existing login names or request a new 
password should be provided. 

As in the client/server world, a single or universal log-in is advised, especially for 
systems that wish to personalize their site's interaction. If the enterprise already has 
5 an existing user base, pushing out IDs to users or allowing the ability to re-use the 
existing ID should be encouraged. For example, United Airlines created a PIN 
(Personal Identification Number) for each of their Mileage Plus members that 
provided access to the Mileage Plus section of their Web site and pushed (physically 
mailed) this out to the respective user. The PIN was their mileage plus number with 

yl 10 a password associated with it. By doing this, they were able to reuse their existing 

I J identification process and login IDs. 
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y3 The personalization process is data intensive and is driven by the information 

15 collected about the system's users. The more information the site collects and 
retains about a user, the more likely it can add value and interact on a personalized 
level. With out this crucial data, there is no basis to shape the interaction or drive 
the personalization techniques. 

Personalization Profile 

20 The information collected about a user is considered the user's profile. Logically, 
this is everything the enterprise (site) knows about the user. Attributes from the 
user's profile will be the input to the personalization process and the driving data for 
the different personalization techniques. A profiling strategy should be developed 
by the enterprise that addresses what information to capture, the sources of this 
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information, the methods to capture it, and how this information will be stored. If 
the customer is to be treated the same at all points of interaction, a common profile 
should be developed that is shared by all departments and applications. 

Determining what information to capture or what attributes make up the user's 
profile can be a difficult process. In most cases, the profile will be based on the 
enterprise's personalization strategy, the personalization techniques to be 
implemented, the data required to implement them and a mix of any user information 
deemed usable that can be captured. In general, the site needs to capture the 
information required to perform the analysis aspect of the personalization process for 
each of the personalization technique to be implemented. This information might 
include: 

• Basic user information such as name and address. 

• User demographics, psychographics, and sonographics such as 
gender, height or age. 

• User transaction or enterprise data such as purchase history. 

• User's specified configuration information such as the 
attribute's of the user's personal home page. 

• Interaction information such as content viewed or duration of 
content displayed to the user. 

Each personalization technique may require a different set of attributes from the 
user's profile. The information needed to deliver a 'Site Controlled Contextual 
Inferences' will be very different than the information needed for 'pre-filled forms.' 
Site Controlled Contextual Inferences Content Filtering requires the creation of rules 



• # 

- 429 - 

and the necessary user information that satisfy the rules or 'Contextual Inferences'. 
(The information required to satisfy a rule is referred to as Personalization Matching 
Factors (PMFs) and will be discussed in more detail in the Matching Logic 
component.) For instance, the rule may be based on gender, age, purchase history or 
5 customer demographics. On the other hand, the information that is used to Pre-Fill 
forms may be a different set of user profile attributes. For example, this might be 
name, address, shipping information and payment information. Another 
personalization technique may use the same set of user information or may require 
another subset of user data. 

Physically, this data may come from many sources within the enterprise. 
Information may be gathered directly from the user's interaction with the 
personalized site through implicit or explicit information gathering techniques. 
Information may be used from other data sources such as existing application's 
transactional data, the enterprises' data warehouse, or from other internal or external 
data sources. 

The situation should be analyzed to determine if the 'profile data' should be 
replicated and stored in additional profile tables or if it should remain within the 
existing data source. Some personalization techniques will require additional tables 
to store the user's profile attributes needed to deliver the personalization technique. 
This will be discussed in more detail within the Matching section of the paper. 

Profiling Standards 

The industry has recognized the importance of personalization and the requirement 
of a user profile information to deliver personalization. To date, a profiling standard 
or definition of a common 'User Profile' does not exist. This means that each site 
25 will be required to capture and retain its own set of profile information. From a 
user's perspective, this introduces additional annoyance since they will be prompted 
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by personalized sites for the same basic information. The Open Profiling Standard 
has been proposed to address this issue. 



Platform for privacy preferences and open profiling standards 



The Internet Privacy Working Group (IPWG) began to develop the Platform for 
Privacy Preferences (P3P). P3P extends the Platform for Internet Content Selection 
(PICS) standard with notice and consent capabilities to enable automatic negotiation 
of preferences, policies, and information exchange. If P3P settings are accurate, 
Web surfers should be able to surf at will and only see P3P notices when they stray 
out of bounds of what is already approved in the profile. 



Netscape, FireFly Network Inc. and VeriSign have introduced Open Profiling 
Standard (OPS), a proposed standard that helps to address the issues of multiple 
profiles. This proposed standard would provide Internet site developers with a 
uniform way of getting users' Personal Profile information in order to personalize 
interaction. The OPS is a standard being worked on as part of the World Wide Web 
Consortium's Platform for Privacy Preferences (http://www.w3c.orjg ). It is 
compatible with the existing vCard and X.509 digital certificate technology 
standards, which allow for user identification and authentication over the Web. 



Individuals will have a Personal Profile that contains their personal information, 
including their names, e-mail address, mailing address, and any other information 
they wish to provide. This profile will be stored on their personal computer (or 
securely stored in a corporate-wide or global directory). The first time that an 
individual visits a Web site that supports OPS, the Web site will request information 
from the Personal Profile. To protect their privacy, users can decide whether they 
want all or part of the information to be given to publishers, and which ones can see 
it. In addition, if the Web site collects additional information about the individual's 
preferences, it can (with the individual's permission) store that information in the 
Personal Profile for future use. 
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Some of the benefits to the user are as follows: 

• Convenience of maintaining only one set of personal 
information for many Web sites, which can save time and the 
inconvenience of giving the same information to multiple Web 

5 sites. 

• Enhances personal privacy by allowing users, instead of Web 
sites, to have control over releasing this private information to 

f 3 Web sites 

%u 
IS. 

^ • The security that can be offered by possibly encrypting the 

D io locally stored information or the transmission of this 

i\ : information to Web sites. 



Users have the ability to selectively release or withhold information in their Personal 
fjj: Profiles, rather than the "all or nothing" process of accepting or rejecting cookies 

^ that the user cannot examine. OPS gives individuals both more flexibility and more 

15 control over personal information than cookies can. 



P3P and OPS have common goals and have unified their projects. The governing 
term is now P3P. 



Information Capture Techniques 

Once the profile strategy has been defined and the sources have been identified, the 
20 next step is capturing the information. In many cases, the information comes from 
existing data sources. In these cases the data may require refinement or replication. 
The remaining information can be captured directly from the user's interaction with 
the site. 
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In most cases, the user will control the personalization process or technique. In these 
cases the user is aware of the personalization technique and chooses to use the 
interface that will deliver it. For example, a configured interface such as My Yahoo! 
requires the user to select the layout and topics they wish to display on the 
personalized page. The configuration (or setup) interface captures the needed 
information and adds this to the user's logical profile. 

On the other end of the spectrum are information capture techniques that the site 
controls. The site collects information about the interaction. The interactive 
information capture techniques can be categorized as explicit or implicit. 

Explicit information capture 

Explicit information capture usually provides an interface to collect profile 
information. The site explicitly asks the user to provide the information. Examples 
of explicit information capture techniques are: 

• Registration Forms. A form that the user fills out to register to 
the site. This may include interests, demographics or any other 
profile attributes that site has defined and the user may be 
willing to provide. 

• Static or Dynamic Questionnaires. During the interaction, the 
site may prompt the user to answer questions. The questions 
may be based on the answer to the previous question. (Note: 
The registration form or a rating interface may also be an 
example of a questionnaire.) The site might ask a user a 
question if there is a Personalization Knowledge Gap. (A 
Personalization Knowledge Gap is the difference between the 
data required to deliver a specific personalized interaction and 
the amount of information the site has collected on the user.) 
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Another example might be a need assessment questionnaire. For 
example Progressive Insurance's site provides a list of questions 
used to analyze the user's insurance needs. 

• Rating Interface. The site may provide an interface that allows 
the user to rate content or products. A rating interface is often 
used with collaborative filtering. 

• Filter or Query Interface. An interface that allows the user to 
directly manipulate or filter the content that is displayed. 

• Configuration Interface. An interface that allows the user to 
configure the site or select the content to be displayed. 

Implicit information capture 

Implicit Techniques gather information about the interaction without directly asking 
the user. In essence, the site is recording the interaction in search of useful 
information. The user may be unaware that the site is capturing information. The 
most common implicit technique is clickstream analysis. The site records the user's 
actions, what they clicked on or where they navigated to, the content displayed, time 
spent or the duration a graphic was displayed. The information gathered is then 
analyzed for patterns and trends. 

Information Capture Concerns 

The goal of a personalized site is to increase the value of the interaction of the user 
with the organization. Unfortunately, the site has the potential to do the opposite. 
The personalization aspects of the site could actually offend or deter customers. The 
approach the site uses for information capture will play a large part in the 
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personalized site's success. The following are some items to be aware of when 
capturing user profile information: 

• Provide Value. In general, people do not like to give away personal 
information. To overcome this, the site needs to offer value for the 
information capture or provide a win- win situation. If the information 
capture results in something benefiting the user, they are more likely to 
provide the information. A good example is the grocery-preferred card. 
. For instance Jewel Food Stores offered a preferred card where users 
receive discounts off of selected groceries each week. The user must 
present their card to receive the discount. Jewel obtains valuable user 
profile attributes such as purchase history and trends while the customer 
receives tangible discounts. The same analogy can be applied to the 
explicit information capture techniques used by the personalized site. 

• Small Appropriate Questions. Filling out long forms or questionnaires 
can also be an instant turn off. Users don't want to be burdened by 
information capture techniques. They have their own goals and agendas 
and if the site distracts them from accomplishing this, the site risks losing 
a customer. If the information capture is not directly tied to some value 
that the user will instantly see, break it into to small units or single 
questions. In addition, ask only what is needed and when it is 
appropriate. If the user is required to fill out a long questionnaire at the 
start of the interaction or when they first visit the site, they are likely to 
leave. By gathering the information only when it is needed and tied to 
tangible value, the user is more likely to provide accurate information 
and remain at the site. 
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Accuracy Issues. There is nothing that stops the users from lying or 
providing false information. Although there is no sure-fire way to 
prevent this, the site can reduce the possibilities of this occurring. As 
mentioned above, users are more likely to be truthful if when answering 
questions that are tied to perceived value or in small amounts. The site 
should explain the benefit of accurate information and how it will benefit 
the user by serving them better. 

Information may also change over time. The user's interests or their 
marital status may change over time. It may be necessary to occasionally 
verify information. If derived information is stored, these may also 
become inaccurate over time. For example, driver status may change 
over time due to the occurrence of moving violations or a change in 
marital status. The same risks apply to information captured implicitly. 

Privacy Issues. The fine line of a user's personal space and their legal 
rights is another possible area for concern. 

Regulatory Compliance. The details of a user's legal rights are still not 
clear. In the near future, legal regulations will require all companies to 
place privacy statements on their Web sites and to provide customers 
with a mechanism to examine and challenge personal data collected about 
them. Customer access to personal information will be difficult to 
implement due to user authentication requirements, and the unpredictable 
nature of data requests and alterations. In either case, failure to comply 
with a site's stated privacy policy or failure to provide customers with a 
copy of their personal information will mean legal prosecution of 
organizations under national regulations. 



Defining Preferences or Personality. The definition of "private" 
information is open to debate. For example, the European Data Protection 




-436- 



Directive defines a number of areas (e.g., political affiliation) that are 
considered particularly private and, therefore, subject to enhanced 
controls. However, the ability of the Web to follow users' search patterns 
and to customize content provided by certain sites (e.g., most current- 
affairs sites) will offer the de facto ability to identify users' viewing 
preferences without the explicit authorization that the law would require 
if they were identifying their own characteristics. This issue will cause 
the most friction between U.S. and European regulators, as the United 
States tends to assess privacy on the basis of context and usage, while 
Europe bases it on an absolute measure of the data's perceived privacy 
(see Note 1). The collection of data that could be used to derive sensitive 
information will be subject (in each jurisdiction) to the equivalent privacy 
regulations as that level of sensitive information (0.7 probability). 

Children. Vendors whose Web sites are designed for children will be 
subject to greater public scrutiny for violations of privacy regulations and 
conventions. It will be politically sensitive for children's Web sites to 
perform customization of content or context across multiple visits. 

Selling information to third party providers. General data privacy 
guidelines state that information cannot be used in ways not explained to 
the subject at the time of collection. The problem results from the fact 
that the most personal information (e.g., a stock portfolio) is also the 
most valuable when sharing information with other application providers. 
This can cause tension between the value that the Web site provides its 
visitors (in terms of the degree of personalization that it is offering) 
compared with the value it can extract from the service that it provides 
(by sharing the information with advertisers or third-party organizations). 
Managing the conflicting requirements of personalization and 
information sharing will become a key element in determining the 
success of a Web site. 
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Content Catalog 9614 



Today, the Web content of most sites is unmanaged. The enterprise does not utilize a 
method of tracking the content or the attributes of the content. Instead, the enterprise 
5 has a pool of content that may span multiple directories, departments and web 

servers. When content is created it is added to this pool of content by simply adding 
it to the Web server's directory and adding the necessary link required to display it. 
„ The content within this pool may be duplicated, outdated or unused. In short, the 

S3 enterprise has no idea of the extent of the content or information about the attributes 

10 of the content. 

^ Unmanaged content may be an obstacle for personalization. In order to deliver 

s personalized content or filtered content the system must know what content exists 

and the attributes of this content. A content catalog 10000 or content management 
[j= system should be used to manage the enterprise's content. A simple definition of a 

uj 1 5 content catalog is given below. 

What is deemed as content can take many forms. As illustrated in Figure 100, 
content maybe Web pages (HTML pages) 10002, graphics (images) 10004, audio, 
video, or even information 10006 and messages. How this content is stored may 
also take many forms; it may be stored in table, files or directories. The content 

20 catalog needs to be aware of what content exists and where it is stored. This can be 
achieved by retaining attributes of the content and providing indexing to the content. 
Content attributes might be physical properties such as what type of content it is 
(HTML page, graphic, audio file, video file or textual message) or the size of the 
content. The difficulty is attempting to store the heuristic or analytical attributes and 

25 making these attributes available for personalization techniques. The indexing 
strategy should include full text and attribute indexing which provides efficient 
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access for the enterprise's users and potentially any integrated members of the 
enterprise's value chain. 



Matching Logic 9616 

This personalization component needs to provide the intelligence to match the user's 
profile attributes with the correct content and deliver this content to the user. 
Bridging the profile information to the content is truly the heart of the 
personalization architecture. A variety of different approaches can be implemented 
to accomplish this task. The complexity of this matching logic is directly 
proportional to how flexible, robust and dynamic the personalization aspects of the 
site are. 

The Match concept is the process of analyzing the information that is known about 
the user and determining the correct content to display to them. Once the user 
profile attributes have been identified , they must be applied against the rules or 
matching logic defined within the site in order to determine the appropriate content 
to display. Three inputs are required in order to complete the Match process: 

• User Profile Information - This information consists of what is 

known about the user. The processes used to gather this information are 
explained earlier in this section. 

20 • Content Available - The content on the system includes any 

information displayed to the user. In this case, content includes; Images, Text, 
Personalized Statements, Applets, and Digital Information. 
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System Defined Rules or Matching Logic - In order to use the 
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user profile information effectively, one must have a clear set of rules defined 
against which to evaluate each user. The rules are defined to match the user 
information with the content 

5 A simple example of this matching logic is a defined query. The site may provide 
the logic for a user to view their account information. In this case the profile 
information is their user ID or account number, the rule is the defined query 
(SELECT account_info FROM Account where Acct_Id = :User_Acct_Id) and the 
content is the user f s account information stored in Account table. If the content is 

10 stored in a relational or object database, SQL queries are an effective method of 

accessing this data. In this case the 'defined rule' takes the form of a SQL statement. 
Unfortunately, most of the content is not stored in relational databases or is not 
directly related to something as simple as a user's account ID. Instead the content is 
web pages or massive amounts of news feeds and textual information. These 

15 situations require a different and possibly more complex approach and infrastructure 
to perform the matching logic. In this environment, the rules are usually composed 
of Personalization Matching Factors (PMFs). 

Personalization Matching Factor (PMFs) 

A Personalization Matching Factor (PMF) is the building block for a rule. It is the 
20 information required to perform the matching aspect of the personalization process. 
This is the demographic/psychographic/sociographic or any other information that 
will be needed to drive the personalization process. A PMF might be as simple as 
the user's gender or a complex attribute such as driver type that is derived from a 
group of data. Included in the definition of the PMF should be the definition 
25 necessary to create it. 

Developing PMFs will require involvement of the Marketing department and other 
business entities that understand the customer strategy and the enterprise's 
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customers. It is important to understand the customer needs, what the customer 
expects, and what makes a difference to them when determining and creating PMFs. 

PMFs should be restricted to information that can be realistically captured by the site 
as well as information that is reliable and accurate. Conceptually, a PMF can be any 
piece of derived or any conceived information. For example, a PMF could be the 
user's gender, age, marital status, number of children, the number of years they have 
been a customer, their profession, driving record, interests such as sports, travel or 
other leisure activities, favorite color, a personality trait such as if they are detail 
oriented or pessimistic in nature, or any 

otherdemographic/psychographic/sociographic piece of information. How would 
this information be captured? What are the attributes that would be used to derive 
this? What is the accuracy of this information? Why is this PMF used to 
personalize? These are the types of questions that need to be asked when 
determining possible PMFs. 

A PMF needs to have a clear definition and a finite list of possibilities. For example, 
a site may create a PMF called 'Age Classification'. The site would need to define 
what it means by the PMF 'Age Classification'. For this example, age classification 
is simple a logical group of users based on their age. The values would be: 



Age 



Age Classification 



0-12 



Child 



13-19 



Teenager 



20-40 



Young Adult 
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41-64 



Middle Aged 



65-125 



Senior Citizen 



125-200 



Ancient 



A PMF may also be a combination of low level data. If a PMF of 'Insurance Risk' 
were created, the required data would be far more than age. It would need to include 
age, driving history, vehicle, region and potentially other data. 

Rules and Matching Logic 

The PMFs are the building blocks for rules and matching logic. Unlike SQL 
extensions, there is no industry standard method for accessing 4 Web' content and 
creating rules. Some approaches are detailed below. 

Simple Conditional Rules - The simplest process is to define a clear-cut set 
of rules against which to evaluate the PMFs. These rules are generally 
simple and have only a few conditions to evaluate. A simple rule would 
follow this structure: 



User Variable + Comparison Operator + 
Predetermined Value (or PMF) 



Age 

Young Adult (20-40) 



The user variable is a specific user's profile attribute or value for the rule's 
PMF. In this case it is the user's age which may be derived from the user's 
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birth date and the current date. The next element in the structure is a 
comparison operator. The final element is the PMF or the group or data the 
rule is based on. Based on the user's age and the granularity of the PMF the 
rule may have numerous results. Each result may point to a different set of 
defined content. The entire age rule may be something like this: 

User's age = Child (<1 2) deliver content ABC 

= Teenager (13-19) deliver content 

DEF 

= Young Adult (20-40) deliver content 

GHI 

= Middle Aged(4 1-64) deliver content 

JKL 

= Senior (>64) deliver content 

MNO 

A rule will be made more complex with the addition of a logical operator that 
allows a rule to have multiple PMFs. For example a rule may simply be 
'AND' multiple PMFs together. In this example, the rule would look like 
this: 

User Variable A + Comparison Operator + 
Predetermined Value (or PMF) A 



AND 
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User Variable B + Comparison Operator + 
Predetermined Value (or PMF) B 

A piece of the actual rule would look like: 

Age = Young Adult (20-40) 

AND Gender = M (Male) 

This rule would now be the age-gender rule. It evaluates the user's age 
classification and gender. If the users age classification is 'Young Adult' and 
male, then statement evaluates to be true and action is taken or the specified 
content is delivered. 

At first glance, this may appear to be hard coded: If directly placed in a 
script this would be a true statement. Instead, the infrastructure should be 
created that can define rules, evaluate rules, assign a rule to a dynamic 
content area or page, and assign content to specific rule results. Instead of 
hard coding this with in the application or script, the rule component or 
dynamic content area (DCA) is placed in the script. When the DCA is 
encountered, the architecture handles evaluating the rule and matching the 
defined profile attributes to the rule in order to deliver the appropriate 
content. 

Conceptually this is easy, but creating this infrastructure is very difficult. For 
this reason a rule engine or personalization vendor will be brought in. 
Numerous independent software vendors (ISVs) are capitalizing on this niche 
and creating their own proprietary personalization infrastructure. These 
vendors are covered in more detail in the accompanying Vendor document. 
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Forward Chaining Rules - Forward chaining still uses the fundamentals of 
simple rules, but facilitates building upon whatever user information may 
be available at the time. In this case, if only a small amount of information 
about the user is available, then the rules are determined based only upon that 
data. Once more information is gathered, the rules allow for more complex 
conditions to be evaluated against. The rules are set similar to this: 

User Variable + Comparison Operator + 
Predetermined Value (or PMF) 

AND if the following is known 

User Variable + Comparison Operator + 
Predetermined Value (or PMF) 

Age = 20-40 

AND if Gender is known to be = M 

The above rule will be evaluated differently according to the amount of 
information known about the user. For instance, If all that is known about 
the user is his/her age the rule will evaluate in one way, if his/her gender is 
known, then the rule will be evaluated in another way. 

Learning System (Neural Network)- The premise behind the learning 
system is that it will monitor the user's actions and perform differently 
depending upon what the system learns from the user actions. This technique 
is a complex combination of rules and relationships using the user's 
interactions with the site to increase the knowledge of the enterprise about 
the customer. The best way to describe this is with a definition of neural 
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networks. A neural network is a system of programs and data structures 
approximating the operation of the human brain. Typically, a neural network 
is initially "trained" or fed large amounts of data and rules about data 
relationships (for example, A grandfather is older than a person's father is). A 
program can then instruct the network how to behave in response to an 
external stimulus, or it can initiate activity on its own based on the user's 
actions. 

Inductive reasoning/Collaborative Filtering - Firefly defines collaborative 
filtering as a technology that emulate the social processes of people making 
recommendations based on an understanding of one another's preferences. 
Individual agents track and choose items based on individuals' tastes and 
preferences. 

The core technology personalizes both the delivery of content and the 
knowledge of related people within a defined networked environment, or 
"taste space." Firefly tools correlate individual users' preferences for specific 
items based on either explicit or implicit ratings of comparable items in other 
situations. These ratings may be stored entirely within a single Web site or 
compiled on the fly from information assembled from individual clients and 
shared servers. 

Collaborative Filtering assesses a single set of user preferences to identify an 
individual community of interest. Collaborative Filtering correlates the tastes 
on an individual user with the preferences of comparable users to develop a 
list of personalized recommendations. It is some times referred to as People- 
to-people matching, and is aimed at automating word-of-mouth kind of 
information. 
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Canned Queries - A system of canned queries allows the user to choose 
only certain actions that have been pre-determined for the user. The queries 
only give the user the options listed, and do not change over time. 

The examples above are mainly site controlled. The site either has a pre-defined rule 
or matching logic that will execute. The site is responsible for determining what has 
been learned from the interaction, what is enabled based on the knowledge gained, 
what additional information will provide additional insight. Where possible, the 
users should be allowed to define the rules and matching logic or the content they 
wish to view. Provide the user the structure to create a rule or define a query. 

Defining legitimate business rules and models is as important as the infrastructure to 
evaluate them. The rule may execute and content may be delivered but if the rule 
doesn't make good business sense the effort is wasted. Business and marketing 
personnel should be involved in defining the rules and verifying that they are 
correctly translated and technically implemented. This is another reason that the 
personalization team should include individuals from IT, the business and marking 
departments. The team needs to understand their existing and potential customer, 
the content available, and when and why to display it. 



Merge and Deliver Content 961 8 

The rules for matching logic should be defined as stand alone entities so that they 
may be reused in multiple situations. Each situation may associate the same rule to a 
different interaction and a different set of content. The matching logic should be 
associated with a template or interaction and content should be associated with a rule 
result or condition of the matching logic. 
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One possible method of associating a rule and content to an interaction is by using a 
Dynamic Content Area (DCA). A DCA is embedded with a template and points to a 
specific rule, and a rule results set will be associated with specific content. For 
example a page may be explaining a particular service to a current user. The site 
may wish to display on the page a graphic that the user can relate to along with a list 
of benefits that are personalized to the user and finally list discounts that the user 
might be qualified for. 

A separate DCA would be used for each set of data. Figure 101 illustrates an 
exemplary template 10100 with three DCAs embedded within the template. 

• DCA1 10102 might be a place holder for the graphic. The rule associated with 
DCA 1 might be bases on a set of PMFs such as Age and Gender. Depending on 
how the rule is evaluated, a different graphic might be displayed. (In this case a 
graphic is the content.) 

• DCA2 10104 might represent a place holder for a list of benefits the user may 
receive from the service. This rule may be associated with different PMFs. For 
example, the PMFs for this rule might be marital status, number and ages of 
children and income level. Different benefits would be displayed based on how 
this rule is evaluated. In this case a textual statement about benefits is 
considered the content. 

• DCA3 10106 might represent a place holder for discounts. This area may reuse 
the rule created for DCA 2 but the content is different. In this case, the content is 
a list of discount based on the rule evaluation. 

During the design of the site, a decision must be made to determine which areas of 
the site will provide personalized content to the user, the rules to use and matching 
logic associated with it, and what content should be displayed for each rule result. 
Since there is no face-to-face interaction with the user, identifying the content to use 
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is very important. The web site must make the users feel as though they are being 
communicated directly. Once the page is requested or encountered by the user, the 
page is generated, and each DCA will request that a rule be executed and the content 
should be generated according to the user profile. 



5 The normal delivery method of the content is through the use of HTTP. This method 
will be used to deliver the majority of the content. There are other methods of 
delivery that may be considered depending upon the content to be delivered. Other 
delivery methods includes e-mail, FTP, Push or Channels and streaming video. 
Since timing of the delivery is very important, consideration must be given to 

f 3 10 developing a method of delivery that provides the most impact to the user and does 

% so in a timely manner. 
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l Ss Administration 9620 

b 
m 

rU Personalization is difficult for a number of reasons, but the biggest "gotcha" is that, 

15 above all, it requires dedicated maintenance staff. While much of the process of 
personalization can be automated, the construction of the business rules used to 
match content to visitors and the creation of the metadata tags required to classify all 
content still require a tremendous amount of human oversight. The need for such 
oversight is only compounded by the fact that personalization becomes exponentially 
20 more complex as the number of visitors and amount of available content increases. 
The net result is that firms that decide to engage in personalization without ramping 
up staff adequately will fail. 



Personalization is a continuous process. It is not an application that is delivered and 
then left unmonitored or forgotten about. Personalization techniques will need to be 
25 added, removed and modified. Rules, content, and messages will change. Most 
enterprises fail to measure their return on investments, or to directly attribute 
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customer behavior to certain initiatives. As a result, the enterprise often invests in 
initiatives, promotions and campaigns without understanding how they will affect 
product or customer profitability. Procedures, measurement and reporting devices, 
and metrics need to be created to allow for the enterprise to evaluate and improve 
their personalized interactions and deliver their customer strategy. The site may 
provide the customer a chance to make a purchasing decision. If they decide not to 
make this purchase, what is the reason why? The enterprise should attempt to gather 
information on why this result occurs and seek to prevent it in the future. The 
following optimization and administration components should be considered for a 
personalized site: 

• Content Rating and User Feedback. Allow the users to directly 
rate the interaction and the content. The Internet is an 
interactive medium, but unlike a face to face interaction one 
can not read the user's face or inflections in their voice to 
determine if their needs are being met. This type of feedback 
needs to be built into the site. The interface should be simple 
where the user can provide feedback with a single click. 

• Metrics Return On Investment/Information. How can one 
determine if the personalization process is helping the 
enterprise? Metrics should be defined to measure the ROI. 
This might include reporting facilities to capture the information 
needed to provide these metrics. 

• Administration Facilities. When designing a personalization 
site, maintenance of the rules and content should be considered. 
The people most likely driving this information will not be 
technology oriented, and may require simple interfaces for 
altering rules for personalized content. An IS staff member 
should not be needed to change rules. The same holds true for 
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content. As content is added, this information will need to be 
indexed and integrated with the search technology implemented 
at the site. 



5 Interactive Marketing 9602 

With the emergence of interactive mediums and the inherent capability to gather real 
time information about the customer interacting with the medium, enterprise's 
marketing strategies and systems are becoming more customer-centric. With the 
move from mass (or targeted) marketing to a form of customer-centric marketing, 
enterprises must evaluate their customer relationship model. 

Traditionally, marketing models tended to focus exclusively on customer acquisition 
(mass marketing) and then on customer selection (micromarketing and target 
marketing). However, several studies have shown it costs between four and 10 times 
as much to acquire a profitable customer as it does to retain one. This awareness has 
resulted in a heightened emphasis on customer retention and extension and has been 
the driving force of relationship marketing. 

However, customer retention and extension are less dependent on traditional 
marketing and are more tied to the value perceived by the customer during every 
interaction with the enterprise. In addition, these strategies require a different 
20 marketing infrastructure that is information- and customer-driven, rather than 
product- and creative-driven. Thus, relationship marketing is somewhat of a 
misnomer, as adding value to the customer relationship is not simply a marketing 
challenge, but rather a challenge involving every function within the enterprise. This 
business model calls for enterprises to differentiate themselves by consistently 
25 providing superior service at every point of contact with the customer. 
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The ShARE Model 

The ShARE (Selection 9630, Acquisition 9632, Retention 9636, and Extension 
9634) customer relationship model 10200 is detailed in Figure 102. See also Figure 
96. This model addresses the changes in the shift to interactive marketing. Due to 
the emergence of interactive mediums, today's systems now have the ability to 
address all areas of the ShARE model. 



Selection 9630 



The selection portion of the ShARE model deals with determining who within the 
general population will be a company's most profitable customers. Selection deals 
with determining who makes up a product's target audience, and allows a company 
to focus their attention more accurately. This is the area where demographic 
information, such as age, geography, and income are applied to produce a more 
finite list of likely customers. The selection process allows businesses to make 
strategic decisions such as NOT to market a snow shovel in Ecuador. 

Acquisition 9632 

Acquisition focuses on getting a potential customer to use one's service or buy 
one's product in the most efficient way. This area has traditionally focused on mass 
marketing and measuring a business' cost per thousands of consumers reached. The 
classic example of acquisition is Proctor & Gamble's use of daytime television 
dramas in the United States to sell soap, creating what is now called the soap opera. 
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Other methods of acquisition include direct mailings, telephone solicitation, toll free 
order numbers, and, more recently, Internet advertising and online businesses. 

Advertising 

Capitalizing on the two-way interaction and an audience of the general public, 
advertising is often utilized on applications deployed on the Internet. In a 
browser-based implementation, the use of frames or banners creates the 
possibility to dedicate a section of the display to advertising. With most of 
marketing capabilities, the advertising model (services) can vary from simple 
static advertisements to a robust advertising integrated with the personalized 
system. The implementation methods may range from an advertisement Applet 
to advertising services integrated with the personalization system. Detailed 
below are possible services included in a complex advertising implementation. 

• Storage. Storage of the advertising content should be performed in 
the same fashion as the product and electronic merchandising 
content. The content should be so it integrates well with the 
personalization services and user profiles. 

• Integration with Personalization. Ideally, the personalization 
services are separated and can be utilized by multiple applications. 
For personalized advertising, profile information will be gathered and 
the advertising content filtered based on the profiles. A separate 
process will handle the merging and delivery of the content as well as 
changing the advertisements as the user navigates through the site. 
The advertising content may include rich content such as graphics 
and video. 

• Buy Now Services. Microsoft and others are currently working on 
technology to allow a user to click on the advertisement and purchase 
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the item without leaving the site. These technologies are emerging 
and may require a client-side wallet to perform the transaction. The 
push is to provide the ability to quickly purchase items of interest 
without leaving the site of interest to make the purchase. Microsoft 
currently provides this ability using an ActiveX control integrated 
with a Microsoft wallet. Others are sure to follow this trend. 

• Usage Metering and Reconciliation. There are different methods for 
billing for advertising space. The most common billing methods are 
usage which may include: the number of times displayed, the length 
the add is displayed or the number of users to which the ad is 
displayed. Services are needed to record the usage information in 
order to reconcile with the advertisement providers. Since many sites 
are funded by ad revenue, the accuracy of these services is crucial. 



As online advertising and its supporting technology matures, new advertising 
methods will emerge. For example, the use of 'intermercial' (sometimes 
referred to as interstitial - meaning intertwined) ads that automatically pop up 
between pages may prove to be the next method of choice. It is important to 
ensure the advertising services remain flexible and are able to address the 
evolving technology used to implement advertising. 

Retention 9636 

Now that companies know it is cheaper to hang on to existing customers than to find 
new ones, more and more emphasis is being placed on customer retention. 
Retention focuses on keeping customers for as long as possible. The most effective 
way to do this, is to provide excellent customer service at each and every interaction 
with the customer. Since electronic business don't provide traditional customer 
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service, it is important web-based businesses have sites with appropriate support 
functionality. The support should be easy to use, and meet the specific needs of that 
product's consumers. 

Recommendation Services 

Recommendation functions may take up multiple formats. The most common 
format are simple services to allow the site's users to provide direct feedback, 
positive or negative, and recommendations about the content or products on the 
site. By providing these services, the site may create a community where users 
can interact with each other, furthering the site's worth. For example, a sict 
could allow for users to submit book reviews. The information is then available 
for consumption by the general public. While the technology to implement this 
is rather simple, the process may prove to be a little more complex. The process 
includes receiving input, reviewing recommendations, filtering and approving 
content, and then posting the review or recommendations. The lack of a 
filtration or review process could be devastating to a site. 

Another type of recommendation service makes suggestions to its user base. 
These services can range from simple to complex. A more complex 
recommendation service may utilize collaborative filtering. Collaborative 
filtering is the technique of using content or product ratings from the site's user 
base to predict the interest other potential users will have in the content or 
products. Correlation algorithms use the profile information, history, and/or 
input preferences to construct a correlation group of users whose ratings are 
effective predictors for the new user. Prediction algorithms then use the ratings 
and profile information of the users to make predictions of the content they most 
likely will find interesting. (Note: The collaborative filtering technique could be 
implemented within the personalization system.) 



Site Announcements and Event Reminders 
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Additional relationship building techniques are site announcements and 
reminders. The underlying services are again personalized. The site has created 
content which may range from new product announcements based on the 
customer's last visit or reminders of an upcoming event important to the specific 
customer. For example, an event reminder could point out an upcoming 
wedding, personal anniversary or holiday. The user, once reminded, may then 
utilize the site to act on the event. If the site implements complex event 
reminders, additional services may be needed to provide calendar and scheduling 
functionality. These services may also be incorporated with the off-site 
subscription services to provide reminders to users not logged into the site. 

Loyalty and Return Customer Programs 

Creating an environment that promotes customers to return to the site is critical 
for the longevity of the site. Many of the seller-centric implementations will 
utilize membership services and other incentive programs to try and promote 
customers to return. For example, site members would receive discounts and 
additional privileges, thus building a better relationship with the site. Incentives 
like frequent shopper points or access to member only information are other 
common methods. The loyalty programs may require additional logic for 
permissions and content filtering. Most of this may be implemented by 
gathering and using profiles and integration with a complex personalization 
system. 

Return Programs are services geared toward enticing the customer to return to 
the site. The Internet eliminates two main factors affecting customer loyalty. 
The first is proximity. In the brick and mortar medium, customers tend to shop 
(or browse) close to where they live or work. The second factor is time or how 
long a store is open. With the Internet being 7 by 24 and geographically 
independent, these items are no longer relevant. For this reason, considerable 
effort may be geared toward creating return programs. The most common 
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forrns are electronic version of current methods, although they may be more 
effective due to personalization and real-time delivery. 

Push and Off-Site Subscription Services 

This section includes merchandising using email to push information to a user. 
(Note: Subscriptions to sites and information are covered in the Order 
Processing - Fulfillment component.) Many of the common services for storage, 
filtering, formatting and approving content would be utilized. Additional 
services would be needed to push the content to the desired mailing list. Details 
and considerations for using push technology is included in application 
discussing the Netcentric Framework, referenced above. Below are some basic 
services. 

• Subscription Management. Due to the Internet community 
frowning on junk email and spamming, most sites have distributed 
their push marketing using a subscription-oriented approach. 
Services should be provided to allow users to subscribe and un- 
subscribe from the site marketing distributions. 

• Distribution Management. As the user base of the site grows, the 
actual distribution mechanism needs to be robust enough to scale to 
handle the growing user base. Methods of distributing the 



information in a fashion that does not impact the already increasing 
network traffic should be researched. 



Extension 9634 



,3 
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Extension asks businesses to answer the question, "How can one increase the 
loyalty and profitability of this customer?" 

Cross Selling and Up Selling 

Cross Selling and Up Selling are similar to recommendation services. Cross 
selling uses some knowledge of the consumer to suggest complimentary or 
similar products in which the consumer may be interested - "Would you like 
fries with that?" Up selling is an effort to sell more of the same thing, or a better 
version of what the consumer may currently be considering - "Would you like 
that Super Sized?" 

Cross selling and up selling are considered an application or service enabled by 
complex personalization. Although very important from a marketing 
perspective, once the underlying services for complex personalization are in 
place, many of the demand generating applications are now possible. Cross 
selling or up selling could be implemented by product relationships in a 
database. 



MAINTENANCE AND ADMINISTRATION 9408 



Figure 103 illustrates a flowchart for a method 10300 for administrating an e- 
Commerce system on a network. Operation of entities is monitored in 
operation 10302. Entities include server processes, disk space, memory 
availability, CPU utilization, access time to a server, and/or a number of 
connections in an e-Commerce system. In operation 10304, items including 
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merchandising content, currency exchange rates, tax rates, and/or pricing in the 
e-Commerce system are updated at predetermined intervals. In addition, 
external data stored separately from the e-Commerce system is synchronized in 
operation 10306 with internal data stored on the e-Commerce system. Contact 
information received from users of the e-Commerce system is also managed in 
operation 10308. The items are altered based on profiles of the users of the e- 
Commerce system in operation 10310. 

One of the items altered based on the profiles of the users may include price, 
which may be altered to reflect a discount assigned to the user. A search may 
also be performed for the internal data in the e-Commerce system prior to the 
synchronization of the external data. 

As an option, load balancing services may also be performed that initiate and 
stop processes as utilization levels vary in the e-Commerce system. As 
another option, managing of the contact information may further include 
tracking responses to the users of the e-Commerce system. 

As with any system, a support, administration, and maintenance facility and 
procedures need to be put in place to remain operational as well as efficient. In 
general, packaged implementations will only provide minimal maintenance 
and administration facilities leaving the bulk of the burden to the integrator. 
The underlying technology for the facilities may be basic batch 
download/uploads, simple server processes and applications or even browser 
based. It is important to understand the system administration and 
maintenance needs, develop a plan, and stick with it. Some of the areas to 
consider are listed below. Figure 104 illustrates high-level concepts of 
maintenance and administration of the framework. 



System Monitoring Facilities 10400 
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The health of a system can be easily maintained by putting in place monitoring 
facilities and procedures for capturing the system's electronic vital signs. Far 
too often the users of a system are the first to know of system problems while 
the administrators are the last to know. This can be prevented by creating 
automated monitoring facilities for server processes, disk space, memory, CPU 
utilization, access time, number of connections, and other electronic vital 
signs. The complexity of these facilities is open for debate. In addition to 
online monitoring facilities, robust logging, audit trails, and archiving 
capabilities should be included. These will aid in analysis and forecasting of 
system needs. 

System Administration 

The term system administration is a vague term used to categorize the actions 
needed to support a system. This may include starting, stopping, or restarting 
servers or processes, scheduling backups and loads of databases or files, 
recovery procedures or anything else needed to maintain the system. 
Traditional system administration also includes updates to system software, 
packages, and operating systems. Listed below are additional system 
administration considerations an eCommerce system may encounter. 

Merchandise Administration 10402 

The merchandising aspect may introduce additional administration and 
maintenance. Procedures should be put in place to handle sold out 
merchandise and back order items. Updating merchandising content, 
currency, tax, and pricing may need to be performed on a regular basis. The 
merchandise administration facility should be able to handle pricing and 
discount items and have the ability to allow automatic updating and manual 
override capabilities for authorized administrators. 
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Personalization Maintenance Facility 10404 

The biggest challenges in personalization are determining matching rules for 
the businesses market plans, categorization of the profiles, gathering profile 
information, and then developing robust content with adequate content 
indexing. Once these have been established, they should be easily 
maintained. When designing the personalization services, maintenance of 
the rules and content should be considered. The people most likely driving 
this information will not be technology oriented, and may require simple 
interfaces for altering rules for marketing, advertising, or other personalized 
content. 

Content Administration 

As content is added, this information will need to be indexed and integrated 
with the search technology implemented at the site. Other items such as 
customer service chat discussions or review would also need to be purged on 
a regular basis. 

Data Administration 10406 

Many times, utilizing packages to implement an eCommerce solution will 
introduce a proprietary data model for customer and product information. In 
order to make this information accessible to the rest of the organization, the 
information will need to be synchronized with the enterprise data. Services 
may be required to determine changes and synchronize the data. This would 
be true for any information the site gathers not integrated into the enterprise 
data. 



Load Balancing 
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In addition to the monitoring and maintenance facilities, services should be 
considered to stabilize performance. Providing the system is scalable, load 
balancing services would aid in initiating and stopping extra processes as 
utilization levels vary. Processes could be started to handle additional requests 
during peek periods providing the user with a consistent level of performance. 
This is extremely important in periods of peak usage. A good example is the 
fluctuation of the average response times of some of the current electronic 
trading systems during market surges. Times during a market surge were 2-3 
minutes above their average 6-10 second response time. 

Contact Maintenance 10408 

Internet users are quick to point out mistakes and opinions for improvements. 
Sites will receive sporadic emails from users experiencing a variety of 
emotions about the site. Users may sour quickly if actions are not taken or 
noted to items pointed out. Responses to user feedback should be monitored to 
ensure that each message from a user is responded to in some manner. 

Maintenance and Administration of the system is often wrongfully overlooked. It is 
a key component in improving customer satisfaction and building customer 
relationships. Having robust maintenance and administration facilities should 
increase the system's overall stability by reducing the time and cost to identify and 
fix issues, automating processes, and enabling system administers. 

Implementation Considerations 

Information Staging 

The ability to deliver new products and information may be critical to stay ahead or 
match the competition. The speed at which the information can be updated and 
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migrated to production is critical. Be sure to understand the relationship between the 
content changes and the correct procedures to migrate the changes to the production 
system. The ability to maintain and grow the site may prove to be key factors in the 
site's success. 

In most cases, a content staging process should be put in place. In the simplest 
format, the procedures for modifying and adding content, testing, validation of 
content and subject matter, authorization and migration to production should be 
documented. 



ORDER PROCESSING 9410 



Figure 105 illustrates the Order Processing portion 1010 of the eCommerce 
Application Framework 9400. Subsections include Merchandise Selection 10500, 
Check Out 10502, Payment 10504, and Fulfillment 10506. 

Figure 106 illustrates a flowchart for a method 10600 for completing a transaction 
over a network. Information is displayed information about a product for sale in 
operation 10602. Upon receiving an order for purchase of the product in operation 
10604, a price of the product for sale is dynamically generated in operation 10606 
based on the actual price of the product and discounts, taxes, fulfillment costs and/or 
delivery costs. Save and recall of the product and price of the order are also allowed 
in operation 10608. A method of payment is determined in operation 10610. When 
payment is received, the order is fulfilled (see operations 10612 and 10614). 
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A medium for receiving the payment may be via credit based payment, debit based 
payment, and/or electronic cash. Additionally, verification of export restrictions 
with respect to a selected product may also be allowed. 

As an option, the ability to review, update, and cancel the order at any time may be 
allowed. As another option, electronic rights may also be managed. In even a 
further option, order tracking information about a status of the order may also be 
provided. 

Allowing customers the ability to not just browse and interact but complete the 
purchased is crucial for a successful eCommerce solution. This section includes 
many of the capabilities needed to negotiate and perform the entire transaction. The 
transaction begins when the user takes action to purchase the item(s). From a seller- 
centric view, the transaction is initiated once the 'purchase' button is selected. The 
'buy transaction 5 may include sub-transactions such as totaling, payment selection, 
inventory management and purchase authorization. 

It is important to recognize some commerce packages specialize in the transaction 
processing portion of an eCommerce solution. For example, Open Market's OM- 
Transact, does not provide a catalog interface or any of the infrastructure for 
interaction with the potential customer. Instead, it will provide an interface for 
communicating with its transactional infrastructure. 

Each implementation will require specific flow and business logic. The commerce 
packages available today provide generic order processing business capabilities that 
will need to be customized to achieve the specific needs of the business. Illustrated 
in Figure 107 is an example flow of business capabilities needed for complete order 
processing on an eCommerce implementation. The process begins with operation 
10700 which allows browsing and interacting in order to permit selection of 
merchandise in operation 10702. The process ends in operation 10704 with 
settlement. 



♦ # 

- 464 - 



Merchandise Selection 10500 

Some sort of merchandise collection facility is needed. All items of interest 
should be gathered and organized so they can be reviewed prior to purchase. 
The most common approaches are an order form or a metaphor such as a 
shopping cart or basket. 

Shopping Cart Metaphor - The user is enabled to select items and add 
them to his online shopping cart. The items selected will be tracked. The 
user has the ability to add or remove items, review item details, and check 
out and total the items. In addition, the shopping cart should allow the 
user to exit and reenter the store without losing the items he has selected. 

Independent of the medium, the following capabilities should be considered: 

• Order list and information should be consistent with the 
merchandising mechanism. If possible, display the merchandise 
in the same format so it is as appealing as when they order it. 

• The customer should be able to save and recall items, pricing, and 
other order details for the current and previous orders. 

• Allow for additional sales and impulse buying. The checkout 
process is ideal for cross selling or any other form of impulse 
buying. These capabilities should be integrated to the 
merchandise selection facility. 
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Allow for the ability to review, update or even cancel the order at 
any point of the selection purchasing flow. The customer should 
not feel confined or forced to make the purchase. 



Check Out 10502 

The check out phase begins once the user has decided to purchase or order the 
items gathered. A variety of capabilities may be required or may affect this 
process. Listed below are some of the services to consider during the check 
out processing. 

Price Verification 

Given the geographically independent environment and multitude of potential 
customer relationships, many factors may affect the actual pricing. The first 
step in the transaction is determining the price. The price in most cases will be 
dynamically generated based on the actual price of the items, taxes, fulfillment 
or delivery costs, and any other item affecting the price. Ideally, product 
prices, shipping and handling charges and other charges should be maintained 
separately. This functionality should include the ability to handle tax-exempt 
customers and transactions. Sales tax and value added tax logging and auditing 
capabilities should also be included. 

Discounting 

In general, pricing is calculated dynamically. Discounts may be applied for 
many reasons either to specific items or to the entire order. Additional 
discounts may be given for using a preferred payment mechanism. Other 
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implementations may provide discounts at the end of month based on total 
sales. 

Taxes and Tariffs 

The tax issues related to the buying and selling of tangible personal property or 
services through the Internet, are numerous and complex. Questions include 
what products and services are subject to tax, when and where to impose a tax 
on the retail transaction, and what tax (sales or use) the merchant is required to 
collect. Tax calculation functions with an integrated sales tax or value-added 
tax (VAT) engine, able to perform real-time calculations based on customer- 
specified product codes, order point of origin, shipper's address or recipient's 
address should be considered. 

Due to these complexities, most solutions interface with a tax engine to reduce 
the risk and legalities involved with taxes. Most of the commerce packages 
available today interface with the leading tax engines. 

Shipping Charges 

Shipping charges may be applicable for items not fulfilled directly by the site. 
In some cases, the customer's shipping location maybe used to determine their 
taxes and shipping charges. There are a variety of mechanisms for determining 
shipping charges. They include: 

• Price Threshold - Shipping charges will vary according to set 
price tiers. 

• Weight - Shipping charges may be determined based on gross 
shipping weight. 
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• Quantity - Charges may vary dependent on the quantity of items 
ordered. Items may be free up to a given number or shipping 
may be free after a given quantity. 

• Line Item - Designating a specific shipping charge for each line 
item on the order. 

Order Information 

Other basic order information may be gathered during the check out 
processing. The most common method is an order form. The form should be 
easily customizable and may contain a variety of information. 

• Order Form Standard online form with the usual questions: 
Name, Address, shipping location, credit card number, email 
address, etc. The user usually has the ability to submit or decline 
the order at this point. Submitted orders should be encrypted 
automatically by the commerce server. 

• Customer Information (Establishing Customer Location.) If 

the basic customer information has not been gathered earlier in 
the process, it should be gathered before the payment phase. 
For some implementations, customers may wish to remain 
anonymous, but this is rare. 

• Shipping/Billing Address Applications should be capable of 
supporting ship-to addresses independent of and different from 
the bill-to address. This allows billing for a product or service to 
be sent to one location, and the actual product to be delivered to 
another. 
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• Automated Inventory Management. In some cases, trading 
partners may set up Automatic Ordering based on usage or 
schedule. If inventory is used on a regular basis, the re-ordering 
process may be automated. 

• Order Validation Inventory checks and verification of export 
restrictions can be done before the order is placed. Depending 
on when and how the information is gathered this may be done 
anywhere along the process flow or as a background event 
concurrent with the other processes. 

• Purchase Order Creation If the commerce implementation 
integrates with an existing system, it may need to generate 
unique purchase orders. Services to integrate and manage this 
functionality may be required. 

• Determine Payment Mechanism Interaction with the user may 
be required for determining the payment mechanism. Research 
is currently underway to determine if this may also be 
automated. 



Payment 10504 

After a total has been established, a payment method must be determined. A 
variety of mediums can handle the transfer of money. The methods, flow, 
technology, and potentially messaging, will vary by implementation. Issues 
concerning security, liability, and relationship to fulfillment need to be worked 
out. 
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Listed below are some considerations for determining the payment flow and 
mediums to be utilized. 

• Anonymity. If there is a need to allow the users to remain 
anonymous, an anonymous medium may need to be implemented. 
Implementations such as a silent bidding site may require strict 
standards and mediums for anonymity. In general, anonymity is 
not a concern for most implementations. 

• Monetary Transaction Size. If the site will be handling very 
small or very large monetary transactions additional considerations 
will be required. Sites accepting micro value transactions will need 
to plan a process to collect and verify the payment. To make low- 
value transactions cost effective, solutions may sacrifice security. 
In some implementations, it is assumed "some" fraud will occur but 
in such small denominations as to be negligible. 

• Transaction Cost. Depending on the payment method, there are 
numerous potential associated costs. Most mediums have either 
transaction costs or may involve a broker requiring additional fees. 
Understanding the costs associated is important when planning an 
efficient payment system. 

• Audit Trail. Some implementations may record each transaction 
with a unique identifier used to track funds if necessary. 

• Security. In the past, eCommerce has been hampered by the 
absence of secure and robust transaction options. Recent 
development of secure online payment options over the Internet 
have been a primary enabler. Strongly-encrypted online purchase 
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transaction protocols have been developed and integrated into 
software for consumers, merchants, and banks to enable secure 
credit card transactions. 

• Consumer Type. The types of flow and payment medium will vary 
greatly depending on the consumer or purchaser. B-C 
implementations require payment (or at least authorization) once 
the order is placed. For the buyer-centric, trading partner 
relationship, the established infrastructure may handle payments 
using traditional invoicing or an Internet-enabled form of EDI or 
EFT (Electronic Funds Transfer). 

• Electronic Authentication. Some sort of digital signature strategy 
would need to be in place between trading partners and potentially 
the financial institution. 

• Message Standards. Payment instructions must be recognizable to 
all parties involved. 

Payment Methods 

There are a multitude of different vendors and technologies available for 
handling electronic payments. The infrastructure, process, and technology 
may vary dramatically from vendor to vendor. The actual mediums for the 
current payment options fall into these categories: 

o Credit-Based Payment Today, the most 

widely-used electronic payment option is the credit card. With 
the new transaction protocols and security features, credit cards 
can be used on the Internet just as they are in the real world. 
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Consumer confidence is higher with the already familiar standard. 
Current overhead for clearing, settlement and fraud makes credit 
card based solutions uneconomical for transactions of small dollar 
amounts. 

Debit-Based Payment. Payment utilizing this 
method will directly debit and credit accounts. These may take 
the form of debit cards, electronic checks or messages utilizing 
EDI or EFT. 

Electronic Cash. Electronic cash is the 
electronic equivalent of real paper cash. It is usually implemented 
using public-key cryptography, digital signatures and blind 
signatures. Electronic cash is "digital" money on the computer's 
hard disk. Theoretically, the money could be spent in very small 
increments, such as tenths of a cent (U.S.) or less. In an 
electronic cash system there is usually a bank, responsible for 
issuing currency, consumers that obtain cash from either banks or 
brokers and merchants who will accept the digital cash for goods 
and services. In short, the bank, merchant and consumer each 
own a public and private key which is used to encrypt and 
digitally sign the electronic cash. 

Smartcards. A smartcard is a programmable 
storage device the same in size and appearance as a normal credit 
card. It contains a microchip to store and process information. 
Some of these cards can contain stored value in the form of 
digital coins. A lost card means lost value, just like cash. The 
person holding the card can spend the value stored on it at any 
merchant accepting smartcards. This technology is particularly 
useful for online shopping, and is far less vulnerable than systems 
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storing value on a hard disk. Transaction costs for this form of 
payment are very low, enabling the user to conduct micro- 
transactions of one penny or less. Microsoft and several 
computer manufacturers are pushing for standards to incorporate 
smartcard readers into PC keyboards, and most TV set-top 
Internet access devices already have them 

Digital Wallets. Digital wallet software 
facilitates secure, online transactions between the consumer and 
the merchant, and between the merchant and the bank. For the 
consumer, there will soon be literally hundreds of software 
"digital wallets" available. They will likely be free and similar in 
function, running within a web browser. 

Payment Authorization. In many cases, 
consumer sites which implement a credit card payment method 
will require payment authorization. In some cases the actual 
settlement process can not occur until the items are shipped. 

JEPI, being developed by W3C and 
CommerceNet in cooperation with many large technology 
companies, is a standard mechanism for Web clients and servers 
to find out what payment capabilities they have in common, and 
negotiate the payment instrument, protocol, and transport between 
one another. This will be transparent to the user; they will 
simply be told by the wallet software what payment options are 
available at this merchant (along with any available discounts for 
payment type or membership affiliations), and asked to choose. 
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Fulfillment 10506 



The fulfillment process can be complex and will vary depending on the type of 
goods being delivered. Integration to existing systems as well as 
communication of invoices and orders to distributors or trading partners will 
play an important role. 

A tremendous amount of communication and back end processing will be 
needed. Often implementing an eCommerce environment opens the doors to 
review the underlying systems and processes. Potential areas include 
warehouse notifications and P.O. delivery. Print, fax, or sneaker net systems 
may be upgraded to EDI, email, or another electronic medium. Updating and 
improving these processes will be critical for providing customer support. 
Users will come to expect the ability to see the progress of their order as it 
moves from the site to warehouse to their desktop. 

Electronic Distribution 

Soft goods may take the form of information, software, graphics, music or any 
other digital content. Many traditional content providers have imported their 
content to the Internet. Although the revenue generation is less than what they 
achieve through their traditional channels of distribution, publishers and other 
entertainment providers have found the Internet offers a richer, more 
interactive environment to present their content. The Internet provides 
consumers the ability to search, evaluate, transact and personalize the content. 
The Internet will continue to be adopted as an effective distribution channel. 



Site Subscription 
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A very simplistic form of soft goods fulfillment may be achieved by allowing 
the user access to the site. Functions to handle permissions and access would 
be required to prevent unauthorized users or actions. 

A site subscription may be based on different metering technologies. Internet 
metering technologies can be divided into two categories: observational 
metering and usage metering. Observation metering measures site activity 
while usage metering measures the usage of items such as files, bytes or time. 

Electronic Rights Management 

Owners of digital content, including authors and publishers, have been 
searching for a method to protect against the unauthorized distribution of their 
works over the Internet. Most content available on the Internet today is freely 
distributed, often without consideration of the content owner's copyrights and 
appropriate royalties. Protecting Web content is a difficult task. Items such as 
copyrighted words, images and other 'digital' objects need to be protected 
from unauthorized (and endless) duplication. Currently, copyright notices can 
easily be stripped away. There are a few recent developments aimed at 
tracking rights violations. 

Some rights management methods are geared toward identifying legal and 
illegal uses of a document or digital object. These concepts still require 
actively searching the Web for signs of abuse. In essence, the methods still 
allow the content to be extracted and used, basing the majority of the security 
on trust. Other approaches place a 'security wrapper' around the content so it 
can only be accessed by authorized users. 

• Digital Watermark - The most common method 

is to add a digital 'watermarks'. The watermark is embedded in 
the background of the image without changing the overall 
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appearance of the image. An agent, sometimes called a "spider' 
because of the way it crawls the web, can be used to scan the 
Internet for the presence of the image or identifier and report 
unauthorized URL's. The watermark will stay with the image, even 
if it is downloaded. 

Digital Object Identifier (DOI) - This method 
would associate a unique identifier with the digital content. The 
identifier would be permanently associated and could potentially be 
as low level as a paragraph. The DOI concept is only a building 
block and would still need to be incorporated into a rights 
management system. 

Digital Fingerprints - A digital fingerprint is an 
invisible record of who "touched" an electronic document. Services 
would be needed to determine who first misused the document 
(such as by improperly copying or distributing it). Fingerprinting 
electronic documents is content-dependent and is easiest for 
document types with a large number of bits. 

Secure Packaging - This concept prevents the use 
of the information by placing the item in a logical security 
envelope. The user may gain access to the information based on the 
requirements of the security envelope. The security will allow the 
user to see the abstract, price, rules for use, and other pertinent 
information. Upon agreement of payment and/or rules by the end 
user, the user will obtain a key to unlock the document contained 
within the security envelope. 
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CUSTOMER SERVICES 9412 



Figure 108 illustrates a flowchart for a method 10800 for electronically serving 
a customer over a network. An ability to search for information on the 
network is provided via a site in operation 10802. Order tracking information 
for tracking an order is displayed via the site in operation 10804. Return of a 
product is allowed via the site with a purchase price refunded to a customer in 
operation 10806. A training application program is executed in operation 
10808 for training a customer in use of the site over the network. Interaction 
with the customer occurs in real-time via the site by allowing the customer to 
communicate with a customer service representative over the network in 
operation 10810. 

The information capable of being searched may include product information 
and also a status of the order. Also, the customer may communicate with the 
customer service representative by way of a chat room. 

As an option, the purchase history information may also be compiled and 
displayed. As another option, information including policy documentation 
may also be provided. As an additional option, an on-line bulletin board may 
be provided for allowing input from a plurality of customers. 

This category includes any component of the solution meeting a user's need 
normally filled by a human customer service representative. These services 
fall across the marketing, merchandising, order processing, and other 
categories. The customer service aspect of eCommerce is as important as 
selling the actual products. Just as in the world of the paper bill, a lack of 
customer service, or poor customer service, can destroy any relationship the 
user has established with the electronic business. 
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The business drivers for customer service are: 

• increased customer satisfaction 

• reduction of support personnel 

• increased functionality 

• timely information and service 

Conducting commerce on the Internet means allowing direct access to the 
system and its data. New users may have a much lower tolerance for hard to 
understand interfaces and site layout and may require considerable help 
understanding what information exists on the site and how to find it. Customer 
service will continue to be a key component in maintaining customer 
relationships. 

There are a variety of different services to enhance customer service. Which 
services should be implemented are dependent on the goals and characteristics 
of the site. Below are listed the key customer services, which are also found in 
Figure 109. 



Site Search 10900 



Search engines have become a popular component of any information- 
intensive site. The ability to lead a user to the type of information he is 
looking for will not only make the interaction more efficient but enhance the 
customer relationships. "Search" is a generic term and may be used for 
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searching for a specific product or may be implemented to search for a specific 
customer's order or other information. 



Order Tracking (Order Management) 10902 

Providing customers the ability to track their orders can provide tremendous 
benefits in reduction of support personnel and building customer relationships. 
Applications of this nature can range from simple to complex depending on the 
level of detail. The order tracking system should be integrated within the order 
processing's innate workflow system. Purchase history functions may also be 
provided. 



Return Merchandise/Credit 10904 

If the site sells goods, there is always the possibility of the customer returning 
the merchandise. As with most exception processing, this can create numerous 
problems, though the return should be allowed. Actually crediting a smartcard 
or replacing digital currency may be very difficult. The legalities and 
procedures should be thought out and documentation provided. 



Help & Information 10906 and Troubleshooting 10908 



There is a tremendous amount of help and information features a site may 
provide. Listed below are some of the more common examples. 
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• Policy Documents - Documentation stating the policies of the site. 
In some cases this is required for legal reasons. In general it is 
important to layout the site's policies and procedures. 

• Email /Comments/Contact Merchant - Providing mechanisms 
where the user can easily contact the site is a good practice. 
Valuable input and comments can be gained from the actual users. 
Some implementations may allow users to rate site content. This 
functionality can be thought of as a virtual suggestion box. 

• Online Help and Training (Site navigation) - Whether the site is 
Intranet or Internet, the users should have the ability to gain help on 
navigation and usage of the site. In more robust cases, interactive 
training may be offered if it will improve site performance and 
utilization. 

• Store Locator - Many customers may use a site for pricing and 
product research and may not be comfortable purchasing items over 
an electronic medium. If the site has brick and mortar store 
locations, provide a facility for the tentative consumer to find them. 

• Trouble Help Desk - Most help desk functions can be provided 
through a web site. These services can range from simple 
documents, such as trouble shouting guides and FAQs, to complex 
applications. 



Collaboration Services 



t 
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Behind security, one of the leading reasons a customer will not 'transact 5 
online is the lack of human contact. Although unbelievable to most 
technologists, there is still an underlying fear of computers hidden in a large 
percentage of the potential consumer base. Currently, most seller-centric sites 
do not provide a truly two-way, interactive, or collaborative environment. The 
site may have a complex form of personalization which will filter and deliver 
content geared to the specific user, but in most cases will not provide real-time 
customer interaction. Interaction may be delivered in the following methods: 



interact directly with the customers through the site. In the 
simplest form this may be a real time, textual chat function letting 
hesitant shoppers ask questions to either a service or sales 
representative. Technology and bandwidth considerations would 
have to be reviewed before audio or video type solutions could be 
considered. 

o Community - An online community of 

interest for customers. The purpose of a community is to build an 
interest in the site so the customers will return simply to interact 
and gain information (and potentially purchase items). This may 
include additional information about the products or industry not 
normally included in the traditional merchandising approach. 



For additional detail on collaboration services, please refer to the Collaboration 
Delivery Vehicle in DAF, found above. 



o 



Customer Service Chat - Service provided to 



SECURITY 9414 
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Figure 110 illustrates the Security component 1014 of the eCommerce Application 
Framework in accordance with one embodiment of the present invention. Its various 
subcomponents are discussed below. 

Figure 111 illustrates a flowchart for a method 11100 for ensuring security of an e- 
Commerce system on a network. In operation 11102, a message digest is attached to 
data prior to a transmission for determining whether the data was modified after 
being sent by a user. The data is also encrypted in operation 11104 for preventing 
unauthorized access to the data during the transmission. Authentication information 
is sent with the data in the transmission for verifying an identity of the user in 
operation 11106. A client environment is secured by using authorization models to 
determine which entities can access specific applications, data, and resources on a 
client in operation 11108. A server environment is secured by implementing a 
firewall in operation 11110. 

The message digest may include a log of times when modifications to the data 
occurred. The authentication information may also include a digital signature. In 
addition, the authentication information may further include a certification. Further, 
the certification may include a user identifier, a service identifier, a public key which 
is used to verify the digital signature, a name of an issuer of the certification, a 
period which the certification is valid, and an email address. 

In the last few years, computer crimes have exploded - hackers have defaced the 
web site of the CIA, stolen information and software from NASA and the Pentagon, 
and made unauthorized wire transfers causing banks to lose millions. According to 
WarRoom Research, financial losses from computer crime run at $10 billion a year. 
Historically, 80% of security problems have been internal ones - either from 
employees exceeding their level of authorization or ones that are disgruntled. 
Netcentric computing and eCommerce are increasing the risks due to rapidly 
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evolving technology infrastructures. As access to corporate systems is extended 
virtually and new security holes are discovered daily, security issues become 
complex. 

eCommerce, while providing immense potential business advantages, may also 
expose businesses to significant risks. If their systems are broken into, they are at 
risk to financial loss, embarrassment, lost customers, and potential legal liability. 
Businesses often hesitate to take advantage of eCommerce because they fear security 
problems. Although security technologies are continually evolving to mitigate these 
eCommerce security risks, security breeches occur because businesses fail to 
implement an appropriate mixture of security solutions. 

The problems associated with connecting the network to the vast Internet are widely 
published. Hackers abound, and new methods for compromising networks are 
published almost daily. However, what about connecting the network to a partner for 
project collaboration, or perhaps a supplier for automatic inventory control? One 
might trust their supplier, however, does one really know how well their network is 
secured? Contracts and Service Levels can and should deal with many of these 
issues, however, technology can also be used to enforce security policies. 

Once the correct mixture of security solutions has been implemented, the company 
will experience many benefits besides peace of mind that their site is secure. 
Security also allows people to conduct business functions over the Internet which 
previously could only be done in person or with a more private connection. This 
allows expansion into new markets and new business capabilities, increases 
efficiency, and reduces the cost of doing business. For example, in the typical 
electronic storefront scenario, security is enabling an unknown buyer and seller to 
exchange goods with a reasonable assurance that the transaction will be honored on 
both ends. Security can also be a selling point for a company's eCommerce services. 
By demonstrating an increased level of trust and reduced exposure to fraud, a 
customer may choose one merchant's services over another's. Furthermore, 
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eCommerce technologies rely on electronic automated security rather than imprecise 
procedural security. This can result in more reliable processing and fewer errors. 

Unless customers and users feel the system is secure and there is little to no risk 
involved with using the system, the implementation will not be successful. 
Depending on the system, the amount of security in the different security areas will 
vary. By securing all aspects of the site, it will make it extremely difficult for an 
intruder to work their way into the system without being detected. There are a 
number of different approaches which can be employed to provide system security. 
Among the most common, are firewalling, encryption, and authentication. Each 
provides a particular type and degree of security, and in many instances it makes 
sense to use multiple technologies together to achieve the desired result. Security 
must be built into a system extremely carefully in order to be effective. 

The details of security in eCommerce will be discussed in terms of five eCommerce 
cross-component application types. The five application types discussed are: 

• Advertise Product Online 

• Collaboration 

• Interactive Customer Service 

• Internet Home Banking 

• Online Storefront/Product Sales 



Secure Communication 11000 
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Visa ©and MasterCard ® have jointly developed the Secure Electronic 
Transaction (SET) protocol to allow secure, cost-effective bank-card 
transactions over open networks. SET includes facilities for: 



Purchasing goods and services electronically 



• Requesting payment authorization 



Requesting certificates for authentication 



Consumers get their encryption keys using a specific program integrated into 
their browser. This program automatically converts a consumer's credit card 
number into a certificate given by Visa or MasterCard. This certificate contains 
a key and will be attached permanently to the browser of the consumer. 

Then, for every transaction the consumer asks the merchant to send his 
certificate, and the merchant can ask the consumer's bank for authentication 
with the customer's certificate. 

Full implementation of SET requires certificates be issued for each credit card 
a consumer wishes to use on the Internet. This raises enormous administrative 
challenges, as well as the problems involved in achieving this level of 
universal adoption. 



Secure Environment 11002 

There are different technical approaches for Internet security. The end goal of 
the security technologies is the same. It is important to pay attention to the 
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approach and questions that they try to answer. For example Secure Socket 
Layer (SSL) and Secure HTTP (SHTTP) have been viewed as competing 
technology. SSL uses the TCPI/IP protocol to provide transaction security at 
the transport level. Security properties are linked to the channel of 
communication between the two parties. The issue they are addressing is 
channel privacy for a conversation or transaction. SHTTP provides transaction 
security at the document level. Each document is designated as private by the 
sender. This approach is addressing the question of authentication and 
authorization of web transactions. 



Secure Date 11004 

The first area to secure is data. It has to be ensured information is protected 
from unauthorized access. This is mostly important when sensitive data, such 
as credit card numbers or business figures, are transmitted. Data usually passes 
a long way before reaching its final destination and can easily be read by a 
third party. Data, therefore, has to be encrypted before transmission. Today 
several encryption techniques are used which ensure the data is unusable if 
intercepted. 

In addition to encrypting the data, the parties involved in an electronic 
transaction need to know that the data received or sent is secure. 
Authentication techniques require the identities of the sender and receiver are 
known and the information sent arrives unaltered. Authentication can be 
accomplished with both the use of a message digest and a digital signature. 
Details on some of these techniques are discussed below. 



Cryptography 
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Cryptography is an essential component in securing data. In the most basic 
sense, cryptography is encrypting and decrypting data using an algorithm(s) or 
key of some sort. Encrypted data is useless without the key to decrypt it. 
Today several encryption standards exist utilizing a wide variety of algorithms 
5 and keys. Details on some of the different methods can be found in the 

Security for Internet Electronic Commerce Security Technology Handbook. 

Message Digest 

S3 A message digest is used to make sure no one has altered the message between 

4J transmission and reception. It is used to provide data-integrity. A digest is 

f lj 10 associated with a sent message. The recipient can re-compute the digest and 

El- compare the new one with the sent one. If they match, the message has not 

u been tampered during transmission. The algorithm used to compute digest 

r must be the same for the sender and the recipient. A message digest is a short, 

fU- fixed-length digital code derived in a one-way fashion from a longer variable- 

ru 

r[j: 15 length message. As a result, it is impossible to determine the original message 

*~ on the basis of the digest or to find a different message with the same digest. 

Digital Signature 

Digital signatures ensure the message recipient only the sender of the message 
could have sent it. The sender signs a message by encrypting a digest of the 

20 message with their private key. No one but the particular sender could have 

generated the digest corresponding to the message. This provides 
authentication of the sender as well as non-repudiation of the origin. 
Encrypting a message digest also links the signature with the message content. 
The sender can't claim they did not send the message or the message is not the 

25 one they sent. 



Certification 
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Some security techniques may require the use of a public key for encrypting 
data. When using a public keys, issues may arise with key management and 
verification. Often a trusted third party will be needed to issue a Certification 
Authority (CA) for keys and signatures. Certification Authority declares 
which public key and signatures belongs to which users and services. Because 
a user needs the CA public key to check validity of certificates, CA must 
provide a way to safely deliver its own public key. 

A certificate typically contains: 



• User and service identifier 



• Actual public keys 



• A public key, which can be used to verify the digital signature of 
a message sender 



• The name of the issuer, or Certification Authority 



• The certificate's validity period 



• Other identifying information such as email address 
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The client environment should also be secured. Since systems may be open to 
public use, and accessible to a large audience, it could be subject to new types 
of attacks. An environment must have security mechanisms in place to control 
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who can access it as well as controls on the actions these users may perform. 
This may be achieved using authorization models. Authorization models are 
used to determine which entities (for example, people or applications) can 
access specific applications, data, or resources. 

With the onset on Netcentric computing, entire applications or other forms of 
executable content may be downloaded across a network. This style of 
computing introduces a variety of security concerns. Downloads may come in 
the form of applications, applets, ActiveX controls, scripts and a variety of 
other software. It is important to understand the different security concerns 
with the downloads. 

Java Applets 

Java is designed for developing programs to run on many different kinds of 
computers connected together in a network. A Java Applet is a special kind of 
Java program attached to a Web page. Applets are embedded into a Web page's 
HTML definition and interpreted by Java-enabled browser. It is possible to 
have users download the applet from the Web and run the program locally. 

Running some unknown person's untrusted code is also inherently dangerous. 
For this reason, Java restricts the behavior of Applets to a set of safe actions 
(Safe applets are labeled as trusted applets). The Java security model restricts 
an Applet as follows: 



Applets cannot make direct system calls 



Applets are forbidden to: 



1 . access the file system 



• 
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2. open sockets (except on the originating server) 



3. interfere with other applets 



4. spy on the local environment 



Because of its built-in security model, Java addresses these risks head-on. 
Unfortunately, there are still holes in Java's security model which allow some 
risks. For example, applets could be created to perform various harmful acts: 

• Denial of service; This kind of hostile applet takes all the available 
system resources of the user's machine 

• Invasion of privacy; These Applets can publicize private 
information. 

• Annoyance; These types of Applets play sound files, display 
graphics, or create endless windows. 



ActiveX is a technology developed by the Microsoft Corporation for 
distributing software over the Internet. Like Java Applets, an ActiveX 
"control" can be embedded in a Web page, where it typically appears as a 
smart interactive graphic. Unlike Java, which is a platform-independent 
programming language, ActiveX controls are distributed as executable 
binaries, and must be separately compiled for each target machine and 
operating system. 



ActiveX 
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The ActiveX security model is considerably different from Java Applets. 
ActiveX places no restrictions on what a control can do. Instead, each ActiveX 
control can be digitally "signed" by its author in such a way that the signature 
cannot be altered or repudiated. The digital signatures can then be certified by 
a trusted "certifying authority", such as VeriSign, to create the equivalent of a 
shrink-wrapped software package. If downloading a signed ActiveX control 
causes a machine to crash , the responsible party will be identifiable.. 

This security model places the responsibility for the computer system's security 
on the user. Before the browser downloads an ActiveX control that has not 
been signed at all, or has been signed but certified by an unknown certifying 
authority, the browser presents a dialog box warning the user this action may 
not be safe. The user can abort the transfer, or may continue the transfer and 
take his chances. 

Scripting Languages 

Internet scripting languages are programming languages embedded in HTML 
pages and are interpreted by the user's browser (for example, Netscape 
Navigator or Microsoft Explorer). Typically, they are dedicated to control the 
user's interaction with an HTML document, for example when: 



• Processing mouse events 



Opening new windows 



Checking forms 



• Interacting with other active content 
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As scripts are pieces of code from a foreign source executed on the user 
system, they raise security issues. Indeed, a user must be sure a downloaded 
script will not perform malicious actions against his system. Scripting 
languages designers have to manage the balance between security achieved 
through restriction, and language capabilities. 
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Securing the server environment will depend upon the technology and 
architecture of the implementation. Techniques and security models exist for 
the different methods of server-side computing. Included below is basic 
security information for some of the different technologies. 

Internet Firewall 

A firewall is used to protect a trusted network from an untrusted network. 
Typically, the two networks in question are an organization's internal network 
(trusted) and the Internet (untrusted). A firewall is a system or group of 
systems that enforces an access control policy between two networks. A 
firewall is a collection of components or a system placed between two 
networks and possesses the following properties: 



• All traffic from inside to outside, and vice-versa, must pass 
through it; 



• Only authorized traffic, as defined by the local security policy, is 
allowed to pass through it; 



* • 
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• The system itself is immune to penetration. 
Common Gateway Interface (CGI) 

Common Gateway Interface (CGI) scripts are a way of processing information 
submitted to the web server using a form. A CGI script can be written in any 
language able to use standard IN and OUT streams (usually Perl or C shell). To 
process a form, the client first submits the information content to the server. 
On the server, a CGI script reads the form contents, then uses it to write a new 
HTML page, which is sent back from the server to the client. Security 
problems with CGI scripts occur on both the client and the server sides. 

CGI Client Side 

Submitting a form to a CGI script, which is located on a server, implies the 
sending of the contents of this form over the Network. If the channel used is 
not safe, form content can easily be read and perverted. Any way of securing 
the channel, such as SSL, PCT, or S-HTTP, can be used to achieve 
confidentiality of submitted information. As these protocols must be 
implemented by both client and server, a user must check the server is able to 
secure the channel. Current popular browsers are able to warn the user if 
information is being submitted in an unsafe fashion. 

CGI Server Side 

Processing a form on the server, using server resources, such as system 
commands, can lead to security holes. Indeed, forms can be full of malicious 
content causing the server to perform confidential information delivery, server 
crashes, or unauthorized accesses. 
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The only way to protect a server from attacks through CGI script is to be very 
careful when writing, testing, and using CGI scripts. As far as possible, CGI 
scripts should avoid executing system commands. Each submitting entry 
should be checked and analyzed before being processed. Script sources must 
be hidden as analyzing the source of a script is the best way to find an efficient 
attack through it. On multiple user systems, the right to install CGI scripts 
should only be granted to the administrator or trustworthy users. 

Common Object Request Broker (CORBA) 

The Common Object Request Broker architecture is an open distributed object 
computing infrastructure standardized by the Object Management Group. 
CORBA specifies the interfaces, structures and policies used by distributed 
objects (components) to communicate independently of the language, 
operating systems, machine, or network. 

The CORBA 2.0 specification presents a good set of security policies which 
provide authentication, data integrity, confidentiality and non-repudiation. 
The standard leaves to the applications the problem of handling the non- 
repudiation policies without conforming to the ISO specifications. The 
standard does not thoroughly solve the problem of interoperability between 
different security domains. 

Distributed Component Object Model (DCOM) 

The Microsoft Component Object Model (COM) provides a model based on 
Object Technology, to manage inter-process communication on a local 
computer. Microsoft's Distributed Component Object Model is an extension of 
COM, supporting the distribution of collaborative processes over a network. 



-494- 



Security issues in DCOM concern:* 

• Security for communication; Inter-process communication 
messages are sent on potentially unsecured networks like the 
Internet. 

• System administration considerations; Using a DCOM-aware 
application involves the possibility for a user to manage processes 
on others systems. This must not conflict with the user's rights on 
each system. 

Remote Method Invocation (RMI) 

The Remote Method Invocation allows a programmer to create distributed 
Java-to-Java applications. This allows remote Java objects to be invoked from 
other Java virtual machines, even those on different hosts. A Java program can 
call a remote object only when it has obtained a reference to that remote object. 
This can be done by: 

• Searching for the remote object using the bootstrap naming service 
provided by RML 

• Receiving the reference as an argument or a return value. 

A client can call a remote object on a server, and that server can also act as a 
client when calling other remote objects. As RMI both implies execution of 
foreign code and communication over a network, deploying RMI requires a 
secured environment and secured communication. 
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The RMI specification does not define any security features for distributed 
transactions. In order to secure the transfer of information between hosts 
located in different address spaces, some security features need to be added to 
the specification. 

Although only a few embodiments of the present invention have been described in 
detail herein, it should be understood that the present invention may be embodied in 
many other specific forms without departing from the spirit or scope of the 
invention. Therefore, the present examples and embodiments are to be considered 
as illustrative and not restrictive, and the invention is not to be limited to the details 
given herein, but may be modified within the scope of the appended claims. 



